(Originally published in Computerworld February 2003)
Stop blaming the IT department for crappy business processes and move on from Y2K-induced budget squeezes.
Let me start by apologising to all and sundry. The phantom Y2K problem was really my fault. I own up, I know it took ages to arrive at this apology but there you have it. Blame me, I created the problem so all the millions of dollars you spent fixing it are my fault entirely. So sue me.
I know most of you won't believe that it was my fault but someone has to finally step up and take the blame for it. That way the rest of IT can actually put the grieving period behind and move on. It took a lot of guts for the various CIOs to stand up and ask the board to take them seriously for once and actually allocate some budget to avert a looming problem. It took guts to admit that this was a serious problem.
Now for those of you just back from a quick round trip to the galaxy or just one of those countries that still exists on this planet without television, telephone, newspapers or any kind of contact with the rest of the world let me fill you in.
From the time computers were invented until about 1995 give or take a decade, systems stored dates in a six-digit field made up of day month and year. Since computers were not invented until after the start of the twentieth century it was assumed that all dates started with 19 so why bother storing the 19? This was praised as good practice by all and sundry but especially by the bean counters that reasoned that disk storage cost a lot of money, so why waste space on data that could be easily replicated such as a date.
What's more once programmers got wind of compressed numeric fields they started storing the same dates in three or four digit fields. Hands up those of you that remember what a ‘COMP-3' field is. It's a numeric signed field that takes less space than an uncompressed field. Depending on the size you may save one or more bytes after you allocate one byte for the sign. Those of you that think programming didn't exist before Java finish your milk and cookies and get your blankey for your afternoon nap. Ok, here endeth the Cobol lesson.
Headache
Some systems developers distinguished themselves when they started storing seven digits for the date in the same space as the six digits. They reasoned the extra digit didn't take any more space and it could be used to signify the century. To avoid costly rewrites they also assumed that zero would represent the 20th century, one the 21st century and so on.
Such visionaries were few and far in between. The rest of the world awoke sometime between 1995 and 1999 with a potential headache. Doomsayers ran around predicting that planes and satellites would fall out of the sky. Trains would stop running, elevators would stop elevating and cows would run out of milk. The latter group were quickly rounded up and were quietly locked away for a few years with a mandate to create a new tax system, but that's another story.
The rest of us rolled up our collective sleeves and started figuring out what to do next. Lo and behold it came to pass that dates had to be fixed and systems had to be tested. And we set about testing and fixing and testing even more and fixing. And budgets grew and Cobol programmers were scarce. And people started to panic because the deadline moved closer and the deadline was immovable.
So more people were hired and Cobol programmers became minor deities and people came forth to worship. As the deadline moved closer budgets got even bigger and more people were trained to address the problem.
But there was panic in the streets. People started to bulk-purchase bottled water and tinned food and essentials such as soft three-ply toilet paper. Because when the end came and you wanted to kiss your arse goodbye, it would have been important to use soft three-ply paper in the process.
Experts quoted from the prophesies of Nostradamus that earth and fire and water would come together when the great machine maker (Bill Gates) held forth a new operating system (Windows 98) two years hence from the original release date.
And it came to pass that masses of leave got cancelled and thousands of people went to work on New Year's Eve 1999 and at the stroke of midnight nothing happened. Nothing kept happening around the world as time zones clicked over into the new decade. Planes steadfastly refused to fall out of the sky. Satellites stubbornly refused to alter their course and trains ran late as usual. Elevators continued to elevate, cars kept running and account balances stayed the same, except for those that needed to have interest applied.
That dear reader was when things started to get ugly. CIOs were immediately put on the rack and questions were asked on the wisdom of spending all that money to fix systems that had no intention of falling over. Nothing happened? What do you mean nothing happened? How could we have spent so much money and effort on something that didn't happen? Bad CIO, bad, really, really bad! Go sit in the corner, your budget will be slashed and your minions will be fired.
HELLO! Did someone forget to turn off the dumbkoff gas? Of course nothing happened. We took on a monumental task and delivered on time, to specification. Our greatest triumph became our greatest failure. That was the whole point of the exercise! We actually succeeded. But did we sell that success? Did we rest on our laurels? No; we of the propeller head designation shrugged and moved on. So the naysayers took on the fight and convinced everyone that we had done a bad job!
So here it is in black and white. We in IT took on a problem created and perpetuated by the bean counters and we fixed it. We should be congratulated. Why? Because when we were telling the bean counters to buy more storage they kept telling us it was too expensive. When we pointed out systems would not survive the turn of the century we were told by the bean counters not to worry because systems would be replaced by then. When we shouted from the rooftops that systems would crash and burn we finally caught their attention because they saw dollars disappearing from their accounts by the stroke of midnight. And when we finally fixed the problem we took the blame for the whole stinking mess.
No more
Well no more. It's time we made the bean counters accountable. No more cutting IT budgets because if we don't have resources to do our work and time to deliver business requirements systems will fall over and millions will disappear into nether worlds that nobody can fathom.
If we don't have time to get business requirements, if we don't have staff to translate those requirements to systems specs, if we don't deliver systems changes and if we don't have time and resources to test these changes the whole shebang is going to curl up its toes and face the choir invisible. It's going to fall off its perch without the merest titbit of a squawk. There is no point nailing it to the bloody perch and expecting it to crow, if you don't feed it will die.
Now we are telling the bean counters that systems will fail if they get implemented without testing them first. They tell us to go ahead and implement anyway.
For my last trick let me dispel a few myths; IT will not solve your fundamentally screwed up business processes. CRM is not a magic wand. The Web isn't going to save you from a manufacturing process that does not deliver quality. Don't blame IT for your lame marketing department. Using IT as a scapegoat for every ill-timed business decision is a stopgap measure that is bound to fail in the long run.
Here is a thought to keep you warm at night. If BCF takes hold and we continue to ignore achievement and praise failure we might as well forget the golden rule of quality or at the very least revise it.
The price of failure is rework; the price of success is no work.
Tuesday 29 April 2014
The Mythical Project Manager
(Originally published in Computerworld June 2002)
Is it a bird? Is it a plane? No it's Java Project Man. Able to leap to tall conclusions in a single object-oriented bound. Stronger than a Do While statement. More powerful than .Net, disguised as a mild mannered computer professional by day, he sweeps aside deranged architects bent on imposing their lofty distributed processing plans on an unsuspecting mainframe crowd. By night he weaves his magic as project schedules become putty in his hands, massaging a deadline here, extending a critical path there. Cutting back budgets, getting mere team leaders to deliver detailed designs at the blink of an eye. It's Super Project Manager!
Or so it would seem if today's job ads were anything to go by. Never have so many applied for so few jobs only to be disappointed because their J2EE skills are not quite as up to scratch as their five years of .Net expertise. Can anyone spot the oxymoron here? I'll give you a clue. The word 'five' next to the term '.Net'. We are talking major vapourware, people. That didn't stop an overly ambitious headhunter from placing an ad seeking a senior project manager with five years of J2EE and .Net experience. Excuse me for falling out of my chair laughing.
It's a good thing my PMBOK (Project Management Book of Knowledge) manual was there to break my fall. I've spent the last nine months or so applying for various PM roles only to be thwarted at the pass by some seemingly innocent technical requirement. I was talking to a recruiter friend of mine the other day about the technical requirements posted by most job agents right after the words project manager. His explanation was that there are so many good managers out there looking for a job that they had to differentiate them somehow. Yes, that's right, on the basis of a bunch of TLAs (three-letter acronyms) that most recruiters wouldn't know how to decipher. How lazy are they? Instead of identifying the best candidate for the job, they think they can find him/her by a simple 'Find' command of their resume.
I saw an ad a couple of weeks ago: 'Hogan people, need we say more?' No, please, we Hogan people are mind readers. Please don't waste precious bytes of download data on mere trivialities; however, it would be nice to tell us what kind of Hogan (a banking package) skills you're looking for. Do you want someone who knows DDA (Demand Deposits Application), TDA (Term Deposits Application), ILS (Integrated Loans System), CIS (Customer Information System), RPM (Relationship and Profitability Manager), Umbrella or any of the remaining applications that are fairly mutually exclusive?
This is entirely the opposite to what most PM job ads are looking for. Here's a small sample from today's crop; "Software Development Manager - $120k - Knowledge of Visual Basic and SQL, Visual Studio, C/C++ are desirable." I must get in touch with the Project Management Institute immediately; they seem to have left out VB, SQL, and C++ from the PM Book of Knowledge. According to those misguided souls a project manager needs to be able to do things like manage Scope, Risk and Cost. Not a word about important things like Visual Studio.
"Project Manager Software Development -- Your strong technical and documentation skills will enable you to effectively manage with minimal supervision." Yes, I can see you all nodding in agreement that strong technical skills will go a long way towards cost estimating, budgeting and control. Out of the nine core skills that a project manager needs and indeed manages in the lifetime of a project (Integration, Scope, Time, Cost, Quality, Human Resources, Communications, Risk, & Procurement Management) there is nary a mention of an intimate knowledge of Oracle.
Your strong technical skills will probably cause you to focus too much on why Fred is using in-line performs instead of do-while statements. Meanwhile you should instead be paying attention to the fact that your project is about to go belly-up because none of the designers can agree with the business users on the current scope of your project.
"Data Warehousing Project Manager -- You must have a strong data warehousing background with solid working experience in design, implementation and architecture; you should also have a strong understanding of database development preferably Sybase & SQL Server."
Oh yes, a particular favourite of mine. A PM indeed needs to know Sybase and SQL Server to dazzle his technical team with his abundant skills. Do they ask that the PM must understand how to help the business get value out of their DW? Does the PM understand that a well implemented DW that delivers accurate information in a timely manner will help profitability? No, but he's really good with embedded SQL, so give him the job.
"Project Manager - You should also possess sound technical skills, particularly in the areas of RDBMS (Oracle or SQL Server is preferred) with emphasis on NT Windows and MS Project." Oh dear, a technical knowledge of MS Project. Yes, this is just in case MS Project falls over. The PM must be able to recover the lost data, re-bind the executable and carry out an NT upgrade while he's at it. Does anyone have a clue that whoever wrote the ad is probably someone that has to keep re-taking the 'Using your mouse' course?
But I digress, I really should pay more attention to the ads and change my Prince2 chart to include an intimate knowledge of SQL right along with the bit about "CS5 Reviewing Stage Status", and "PL6 Analyse the Risks". Then I can ad Visual Basic to "SB3 Update the Project Business Case", Sybase to "SU6 Plan the Initiation Stage" and NT Windows knowledge right alongside "IP4 Set Up Project Controls". That ought to get my next project moving along smartly.
Then there are the requirements for industry specific knowledge. Must have FX implementation experience. Must have health industry experience (I see my doctor at least twice a year whether I need it or not, does that count?). Must have implemented infrastructure rollouts. Excuse me but how is a banking customer information system development project different to an electricity account billing system development project? Well, actually they are not all that dissimilar. I should know, I've done both.
In the first instance you have to figure out what the business wants, how much they have to spend, how much time they have to do it in and what resources they can commit. Then you have to plan what needs to be done and get the plan approved. Then you put a project team together and you keep it under control until the team delivers what the business needs. When it's all finished you tell them what a wonderful job your team has done and then you start all over again.
A project manager by definition is someone that manages the process of building software to someone's specification. Although it would be an advantage to understand technology I don't believe that an intimate knowledge of a specific platform or RDBMS is all that important.
What one should be asking is questions like: has this manager ever delivered a project on time? Has she ever run over budget? Did he ever fail to deliver what was promised? How did she manage to avert disaster when the backup site was hit by a runaway semi? Does anyone that worked for her plan to ever work for her again? How many people did he fire last time? How many resigned in disgust? Did anyone hear what was going on during the life of the project? Is the system falling apart? Did the vendor shaft the business with an SLA that shouldn't have seen the light of day?
How silly of me, how would a recruiter hope to answer all these questions and meet her targets for the month. Better use that 'Find' facility in MS-Word and match a couple of TLAs instead.
Meanwhile if you have a need for a top gun PM drop me a line at alex@daidal.com but you better hurry because I'm about to be inundated with offers... Any second now... Now where did I put that XHTML manual?
Is it a bird? Is it a plane? No it's Java Project Man. Able to leap to tall conclusions in a single object-oriented bound. Stronger than a Do While statement. More powerful than .Net, disguised as a mild mannered computer professional by day, he sweeps aside deranged architects bent on imposing their lofty distributed processing plans on an unsuspecting mainframe crowd. By night he weaves his magic as project schedules become putty in his hands, massaging a deadline here, extending a critical path there. Cutting back budgets, getting mere team leaders to deliver detailed designs at the blink of an eye. It's Super Project Manager!
Or so it would seem if today's job ads were anything to go by. Never have so many applied for so few jobs only to be disappointed because their J2EE skills are not quite as up to scratch as their five years of .Net expertise. Can anyone spot the oxymoron here? I'll give you a clue. The word 'five' next to the term '.Net'. We are talking major vapourware, people. That didn't stop an overly ambitious headhunter from placing an ad seeking a senior project manager with five years of J2EE and .Net experience. Excuse me for falling out of my chair laughing.
It's a good thing my PMBOK (Project Management Book of Knowledge) manual was there to break my fall. I've spent the last nine months or so applying for various PM roles only to be thwarted at the pass by some seemingly innocent technical requirement. I was talking to a recruiter friend of mine the other day about the technical requirements posted by most job agents right after the words project manager. His explanation was that there are so many good managers out there looking for a job that they had to differentiate them somehow. Yes, that's right, on the basis of a bunch of TLAs (three-letter acronyms) that most recruiters wouldn't know how to decipher. How lazy are they? Instead of identifying the best candidate for the job, they think they can find him/her by a simple 'Find' command of their resume.
I saw an ad a couple of weeks ago: 'Hogan people, need we say more?' No, please, we Hogan people are mind readers. Please don't waste precious bytes of download data on mere trivialities; however, it would be nice to tell us what kind of Hogan (a banking package) skills you're looking for. Do you want someone who knows DDA (Demand Deposits Application), TDA (Term Deposits Application), ILS (Integrated Loans System), CIS (Customer Information System), RPM (Relationship and Profitability Manager), Umbrella or any of the remaining applications that are fairly mutually exclusive?
This is entirely the opposite to what most PM job ads are looking for. Here's a small sample from today's crop; "Software Development Manager - $120k - Knowledge of Visual Basic and SQL, Visual Studio, C/C++ are desirable." I must get in touch with the Project Management Institute immediately; they seem to have left out VB, SQL, and C++ from the PM Book of Knowledge. According to those misguided souls a project manager needs to be able to do things like manage Scope, Risk and Cost. Not a word about important things like Visual Studio.
"Project Manager Software Development -- Your strong technical and documentation skills will enable you to effectively manage with minimal supervision." Yes, I can see you all nodding in agreement that strong technical skills will go a long way towards cost estimating, budgeting and control. Out of the nine core skills that a project manager needs and indeed manages in the lifetime of a project (Integration, Scope, Time, Cost, Quality, Human Resources, Communications, Risk, & Procurement Management) there is nary a mention of an intimate knowledge of Oracle.
Your strong technical skills will probably cause you to focus too much on why Fred is using in-line performs instead of do-while statements. Meanwhile you should instead be paying attention to the fact that your project is about to go belly-up because none of the designers can agree with the business users on the current scope of your project.
"Data Warehousing Project Manager -- You must have a strong data warehousing background with solid working experience in design, implementation and architecture; you should also have a strong understanding of database development preferably Sybase & SQL Server."
Oh yes, a particular favourite of mine. A PM indeed needs to know Sybase and SQL Server to dazzle his technical team with his abundant skills. Do they ask that the PM must understand how to help the business get value out of their DW? Does the PM understand that a well implemented DW that delivers accurate information in a timely manner will help profitability? No, but he's really good with embedded SQL, so give him the job.
"Project Manager - You should also possess sound technical skills, particularly in the areas of RDBMS (Oracle or SQL Server is preferred) with emphasis on NT Windows and MS Project." Oh dear, a technical knowledge of MS Project. Yes, this is just in case MS Project falls over. The PM must be able to recover the lost data, re-bind the executable and carry out an NT upgrade while he's at it. Does anyone have a clue that whoever wrote the ad is probably someone that has to keep re-taking the 'Using your mouse' course?
But I digress, I really should pay more attention to the ads and change my Prince2 chart to include an intimate knowledge of SQL right along with the bit about "CS5 Reviewing Stage Status", and "PL6 Analyse the Risks". Then I can ad Visual Basic to "SB3 Update the Project Business Case", Sybase to "SU6 Plan the Initiation Stage" and NT Windows knowledge right alongside "IP4 Set Up Project Controls". That ought to get my next project moving along smartly.
Then there are the requirements for industry specific knowledge. Must have FX implementation experience. Must have health industry experience (I see my doctor at least twice a year whether I need it or not, does that count?). Must have implemented infrastructure rollouts. Excuse me but how is a banking customer information system development project different to an electricity account billing system development project? Well, actually they are not all that dissimilar. I should know, I've done both.
In the first instance you have to figure out what the business wants, how much they have to spend, how much time they have to do it in and what resources they can commit. Then you have to plan what needs to be done and get the plan approved. Then you put a project team together and you keep it under control until the team delivers what the business needs. When it's all finished you tell them what a wonderful job your team has done and then you start all over again.
A project manager by definition is someone that manages the process of building software to someone's specification. Although it would be an advantage to understand technology I don't believe that an intimate knowledge of a specific platform or RDBMS is all that important.
What one should be asking is questions like: has this manager ever delivered a project on time? Has she ever run over budget? Did he ever fail to deliver what was promised? How did she manage to avert disaster when the backup site was hit by a runaway semi? Does anyone that worked for her plan to ever work for her again? How many people did he fire last time? How many resigned in disgust? Did anyone hear what was going on during the life of the project? Is the system falling apart? Did the vendor shaft the business with an SLA that shouldn't have seen the light of day?
How silly of me, how would a recruiter hope to answer all these questions and meet her targets for the month. Better use that 'Find' facility in MS-Word and match a couple of TLAs instead.
Meanwhile if you have a need for a top gun PM drop me a line at alex@daidal.com but you better hurry because I'm about to be inundated with offers... Any second now... Now where did I put that XHTML manual?
Subscribe to:
Posts (Atom)