Ignorant Boss! Need Help Explaining Validation!
-
Please help! I am going crazy trying to explain testing and validation to my CEO. He scares the living daylights out of me every time he asks me to develop a new report. I spend hours putting it together and when I release it the first time, he expects it to be completely perfect. If it isn't, he yells foul as if I am not doing my job. Does anybody have a good formal document or first hand experience that I can present to him on proper testing, validation, and auditing procedures? The way I see it, I should develop the report and my General Manager should review and audit it.
What do you think? My stomach is in knots over this.
Edited by - sqlinsite on 08/08/2003 01:50:01 AM
-
Hi sqlinsite,
quote:
Please help! I am going crazy trying to explain testing and validation to my CEO. He scares the living daylights out of me every time he asks me to develop a new report. I spend hours putting it together and when I release it the first time, he expects it to be completely perfect. If it isn't, he yells foul as if I am not doing my job. Does anybody have a good formal document or first hand experience that I can present to him on proper testing, validation, and auditing procedures? The way I see it, I should develop the report and my General Manager should review and audit it.What do you think? My stomach is in knots over this.
hey, I'm in some kind of same situation!
I have to deal nearly every day with those guys
I have my own theory. They learn it some kind of management seminars. Steve Jones has a great example on this.
http://www.sqlservercentral.com/columnists/sjones/managementandit.asp
Now, being serious!
In our company there is for every little piece of paper produced by any IT programms is rigide approval process.
First acceptance, then testing on correctness by the specialists in the several departments, then production.
As for on-the-fly reports directly to management:
Of course, there has to be some testing on new reports. I usually give all stages of reports to my CFO to be approved. He's a mathematician with an understanding for numbers and as former IT boss knows to a certain degree about the problems which can occur while developing.
In most cases it is him advising me, to review numbers very carefully, because he must present them to the CEO and to the board of directors. And there he certainly doesn't want to fail.
As for the hard facts, the numbers, I once said to him, he should think on the implications of wrong numbers for ongoing business, this could lead to wrong business decisions, potentially lower profit and this implies potentially lower bonus for him (this is where you really can get them by the b*lls
).I painted a real dramatic horror scenario. And he said, I should review thoroughfully the report.
Another problem with those guys is the fact, that they don't know you, when things go their usual way, but would immediately tar and feather you when things go wrong, even go wrong because of their own decision
So I decided to see thing fatalistic and say, you can't please them, no matter what you do, and even on those very rare occasions you can, you get nothing more than a warm handshake, if at all since this is obviously your job
On the other hand, also, of course, you have to hold your deadlines, programm thoroughfully and do your best to present the correct report.
In the beginning, there was nothing.
And God said: "Let there be light!"
And there was still nothing, but you could see it.
Cheers,
Frank
--
Frank Kalis
Microsoft SQL Server MVP
Webmaster: http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/[/url] -
I work for a small company and I'm the only computer geek in the office. Basically, I'm what they call a System Builder. It's really hard trying to explain Quality Assurance to two people who have never worked in a large company.
Thanks for the help, Frank. I would love to find some formal documentation somewhere that could help explain the process a little better to these two clowns.
-
Hi sqlinsite,
I can sympathise with you to a degree, but in a company as small as yours, (so it seems) if you don't have a UAT, SAT, Test, or a PPT(pre-production team), and your the man, then due diligence has to fall on your shoulders.
Factor in the time that each of these groups would need to do there part when giving a deliverable time. Stand up grow some rocks, point out what it takes to deliver quality, and let them decide what is more important speed or perfection, and then remind them of what they chose when they question you on it.
Don't whine!!! they'll just slap you around, hell I'd slap you around too(just for whining). If your stomach is really in knots, take up knitting, go into pharmacy (pays better) just get out, because you don't have what it takes! If you decide to stay, just remember it's just a paycheck, nothing else.
Best of luck,
Zach
John Zacharkan
John Zacharkan -
I'd forgotten about that one
.For the reports, I'd add a big DRAFT under the header. When he asks, tell him that the report is in test. You need someone to validate the data.
Steve Jones
-
I like the DRAFT idea a lot! Thanks, Steve. Referring to my own boss, the "test" argument has yet to work with this guy and "validate" means that if the data is right, I get to keep my job. If it's wrong, I get my butt chewed. There's no "atta boy" in this company.
All the best,
Dale
Edited by - DALEC on 08/08/2003 09:57:30 AM
All the best,
DaleAuthor: An Introduction to SQL Server 2005 Management Studio
-
Hang in there, in a few months you'll be the guru for their systems. Ok, maybe with an alcer or two and the manager will still not know how to create a report! You may even know how to run a company
-
I am a finance guy who has been the report developer, creator, requisitioner, initiator, etc. My pattern for developing a report - regardless if I'm the developer or requisitioning it from IT - is to(1)get (or provide) a report format sketch from the requisitioner, (2)obtain check totals from the end user (or provide check totals to the developer), (3)get a report already in use from the system developed by the original application developer and reverse engineer it to determine where it pulls data from and how it references, adds, totals, etc.
Armed with the above, you should be able to create a new report and insure that it will work. If the requisitioner is unable to provide check totals (a payroll report, list of this or that, etc.), the scope is too limited for you to go with. In that case, ask who the requisitioner would suggest that you see to get the check data. Chances are that you can enlist this additional person to check the report too.
And my last suggestion, along with seconding Steve Jones' DRAFT comment, is to not present a finished report, but one left incomplete in some fashion to reinforce the work-in-process aspect and prevent the requisitioner from prematurely accepting a report that hasn't been tested enough times.
-
Hi sqlinsite,
quote:
I work for a small company and I'm the only computer geek in the office. Basically, I'm what they call a System Builder. It's really hard trying to explain Quality Assurance to two people who have never worked in a large company.I think when working for a small company, some things are a little bit more complicated than working in a large company. So, when you have no say 'Quality Management' department or something similar, it strongly depends on you to implement guidelines for this. After all, what a mentioned in my first reply is even more valid for a small company. A wrong business decision could be the first and last one for such a company. You should state this VERY clearly to your bosses. And unless management hasn't approved the reports, I like Steve's idea to place a BIG coloured (if possible) DRAFT in such way on the report that no one (even a blind) can oversee it, and blame this on you
Reminds me on some old apage:
In the kingdom of the blind, the one-eyed man is king
quote:
Thanks for the help, Frank. I would love to find some formal documentation somewhere that could help explain the process a little better to these two clowns.I haven't tried myself, but I'm pretty sure you'll find documents on software quality management, project management, software lifecycle etc... on the web.
But, again, even if you find usefull stuff, it's up to you to communicate it to your two clowns.
Good luck for this somehow never-ending battle
Cheers,
Frank
Edited by - a5xo3z1 on 08/11/2003 12:11:46 AM
--
Frank Kalis
Microsoft SQL Server MVP
Webmaster: http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/[/url] -
I agree that putting DRAFT on it is a good idea, but by the point someone else looks at it you shouldnt really expect them to find anything wrong with the data, maybe only the presentation. That means you need a way to test it to prove it works. How are they going to check to see if its right? No reason you can't do the same thing. Granted, checking your own work isn't as good as independent validation, but it's a good start, rules out a lot of simple errors.
Andy
-
Generally, in the past when I was checking my own work, I would write two or three sql statements to retrieve the same data back. If they all presented the same number, I considered the data good, if one of them was different I'd look into why it was different.
When working with large chunks of data, in my case, this could be several thousand or several million rows depending on the request, I would just do spot checking. Looking at every third row returned or something. It's not the most efficient way to test, but it's better than nothing.
As to how to explain to your boss about validation and testing, use software he uses as an example. Explain that they do not go out and code the software and let the end users tell them what's wrong with it when the menu option doesn't work. They have people who test the application, verify there are no major bugs (in your case incorrect data), and then release the application to the public. If something is wrong with it, they fix it, test it again, and validate it.
-
At my previous job, among many other things, I was responsible for creating reports. I learned early on that what people asked for wasn't really what they wanted. I grew tired of having to justify my code after each new report and started the practice of creating an introduction screen for each report. The intro screen described in plain English what the report was going to generate. For example “This report looks at the following products, X,Y,Y, totals the number shipped from January 1, XXX to getdate() and totals the monthly recurring revenue. Refunds and returns are not calculated in the illustrated recurring revenue.” That last sentence was important because people would take the total products shipped to date, multiple that by the cost and expect to derive the recurring revenue. After I implemented this procedure, I stopped getting grilled over my reports.
Steve’s DRAFT idea is a good one and should provide you a foundation for discussion about the importance of getting another pair of eyes to look at the report. I tell people that my code does exactly what I’ve instructed it to do, right or wrong, and getting a fresh perspective will help flush out problems.
-
I am thinking that many Developers / IS people go through this same thing. Don't take this personal...I used to do this
. I think you need to practice the art of "the aire of Indifference". Since this is the way management usually views employees.I am a developer in a medium sized company, and even though I have access to a Testing despartment, I am not allowed to utilize it since I am developing Internal apps. So, all testing, developing, database maintenace / development, reporting, and user support...falls on me. Yes, I alone support everything and anyone LOL! Needless to say, I am faced with managers all day long but I also understand their frustrations of not being able to easily provide what they need. However, sometimes they seem to want everything (because they saw something cool on some website)...I've been trying to think of a good Acronym for "W.H.I.M".
Anyway, all you can do is the best you can. What I like to do is say "I'm looking over this report, and I was wondering if you would give me some ideas on some of this". Managers love to be included! When you do this, they also have no excuses because THEY are the ones who have designed the report / application!
Well, good luck!
-
quote:
Anyway, all you can do is the best you can. What I like to do is say "I'm looking over this report, and I was wondering if you would give me some ideas on some of this". Managers love to be included! When you do this, they also have no excuses because THEY are the ones who have designed the report / application!well, that's another approach.
Include them, make them think they are important, suggest them your ideas as their, learn some nice little rhetorics.
Should work in +90%
Cheers,
Frank
--
Frank Kalis
Microsoft SQL Server MVP
Webmaster: http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/[/url] -
I wish I could be so diplomatic with my boss. He is a very stubborn Italian who believes that he is always right and thinks he is an expert at databases even though he can hardly spell spreadsheet. When I was asked to do this last report, the table I used was the latest version of a lookup table that he in fact created. However, the data he asked me to run this on was older and had been based on an older version of a table he, in fact, created. Here is the email he wrote me:
quote:
I have only reviewed the first report (SIC 1 Only) and there are numerouserrors from what was requested. The following are some of the problems
I found in the report:
1. Headers are not correct - (these were defined on the requirements doc.)
2. Based on what data is ordered (and checked during your processing), we
should only have rank flags of A1 thru T1. Why do we have over 300 rank
flags of "U" for SIC 1?
3. Why do we have 3 "unknown" descriptions?
4. Why do we have 8 digit SIC Codes for 5 listings on SIC 1's? We only mail
based on 6 digit? (could be purchased after the fact).
Number two above concerns me greatly, this should not be happening in the
data file for primary SIC Code records that are mailed to our prospects.
Based
on your "Mail file validation report" there were no "U" mailed, however, you
are
showing we mailed 45,750.
I want you to review both reports, check and verify the accuracy of the
reports, apply
the proper requirements and resend the corrected reports.
As discussed, If you have ANY questions or something is not "adding up"
correctly
make sure we discuss before you provide any more reports.
How do you deal with an a*@hole like that? The report had "errors" because he couldn't remember that he was using an older table when this data was generated. Therefore, I followed his requirements strictly but used the newest table. Of course, he never apologized. Now you see why my gut starts hurting every time he asks me to run a report.
-sqlinsite-
).
.
. I think you need to practice the art of "the aire of Indifference". Since this is the way management usually views employees.Viewing 15 posts - 1 through 15 (of 24 total)
You must be logged in to reply to this topic. Login to reply