In the SOA project I worked on for the last 3 years the management had a peculiar approach which I found difficult to understand and had me concerned about their competence. I called it Deadline Driven Delivery since it always seemed to be driven by starting with an end date and working backwards.
Three years ago they started with a completely rediculous end date and threw lots of people at it. The end product was said to be important and stategic to the company so there was never any question of leaving out functionality. The technology platform (Oracle Fusion) was new and the SOA paradigm was still not mature in its practices within the industry, especially in a performance sensitive environment. A sensible project manager would be factoring in large contigencies to allow for the many unknown quantities but what can you do when the end date is set ?
Well it doesn't take a genius to work out that we didn't hit the deadline so what happened next ? That's right a new end date was chosen. The criteria seemd to be to make it the most aggressive, wishful thinking date possible. We were told it was going to be "tight and not much room for slippage so we all need to work really hard" - contingency was definitely a dirty word.
Well, wouldn't you know it the real world intervened. There were bugs, there were holdups waiting for hardware and middleware software updates and a list of Change Requests to boggle the mind. Then of course there was performance testing that indicated that the heavy weight SOA approach had performance implications.
Each setback seemed to met with the same approach. Look at original schedule, calculate how much time was lost due to the setback, add that time to the end date of the original schedule, get approval for the new date, work backwards again. Hey look the schedule is still "tight and not much room for slippage so we all need to work really hard".
It was clear to me that each project plan was doomed to fail. If you don't have realistic estimates and you son't allow for contingencies you are just planning to fail. Unfortunately the bigger the project and more ambitious the project the more contingencies need to be allowed for and the harder it is for anyone to agree up front to fund the project.
If I could see it why couldn't the project management. Or maybe they could and just realised that was the way the game had to be played in a business setting ?
This was my first taste of the business dynamic in a project. Before this I worked on projects where the customer would tell us what they wanted, we would prepare a realistic estimate for cost and schedule (with a couple of variations based on number of developers to work on it) and then we might cut functionality or release in stages to meet particular deadlines. This project had a company board that only met monthly at best, an executive control group, the project management, the development technical leadership and then the rest of us developers.
I was a long way from the action but it seemed as though the project was run on the basis of how much expenditure the board would approve and this was the driver for choosing the end dates. I am not sure if anyone ever suggested a realistic schedule to the board and got knocked back. Maybe it is Project Management 101 to never tell the real date for fear of having the project cancelled. I doubt that anyone would have approved a 4 year project (which it will be by the time it is finally finished) at the beginning so maybe planning to fail is the only way to succeed ? The project was nearly cancelled a number of times and a couple of the original project managers were sent on their way so it would not be an approach for the faint hearted.
It also appeared to me that no one was really in control of the project. No one was sufficiently powerful, informed and competent to look at the project, factor in contigencies and approve the real cost to the end of the project. If such a person existed would the project have gone ahead ? Hard to say but
perhaps that person would have seen the real folly of the initial schedule and found ways to reduce the size of the project and release it in stages and jettisoned things that didn't have real value (eg reduced use of SOA to only where it made sense).
We would have weekly standup team meetings to look at the schedule (which I came to regard as the "fantasy schedule") and discuss progress. I tried to determine whether the management actually believed the schedule. There were over 50 people at these standup meetings and there was question time at the end and I was sorely tempted to ask whether anyone actually believed the schedule or whether they had learnt anything from the 20 failed schedules before but I decided to keep my head down and not bring morale down further.
So were the project managers incompetent, business savvy or just out of their depth. Still not sure but I am sure that the Deadline Driven Delivery is not a very healthy process to be a part of.
No comments:
Post a Comment