The delusions of an unreal deadline and its deliverables.
I am in the middle of putting together one of the biggest deliverables I have had the pleasure of creating. It is not however an application, it is a Process Repository that will be used to build instances of processes based on a given project's needs.
It is a 6 to 7 month long time frame for the first build. The project was broken into about 20 iterations. There was an extensive proof of concept done to determine the amount of time it was going to take to finish the first release. The first release will be the baseline repository that will allow additional library data to be added in short release time frames.
When determining the time it would take for each content building iteration I had to set the timeframes as hard stops. If I didn't, I could probably spend months on each content library and still feel like I could do better. The time frame set was 1 week per content library. Content is coming from SEI, Microsoft, books, tools, and websites.
OK, so what? Notice I didn't say the iteration's timeframes were set based on budget, they were set by the amount of content we considered to be enough for our first release. In an application, this would be when a module is 100% complete, tested, bug free, documented, and integrated into the application.
This development process is doing with time what any project should do with time. It is being used to help manage the project, but it is not determining when the project will be completed. Time has absolutely nothing to do with the completion of a project unless we allow it to. Yet it is one of the most determining factors that we allow to mess up a good project. We all know why this happens most of the time, budget or politics. Sometimes it is just poor planning, no proof of concepts done to determine real time frames, and promises made on guess-tamations.
Some of the brightest dumbest people I have had the pleasure of working with are living in a delusion that they can control a project's creation with willpower and authority because they have decided there is a deadline that must be met because of budget or politics.
The rest of us know the deadline simply won't be met, but we also know they can't be convinced of that. If it is met, it is always a fake deliverable. Meaning the deliverable was delivered, the check was cut, the party was thrown, and a maintenance contract costing 3 times the original contract cost was signed to get the deliverable running over the next several months or years.
My responsibilities also include architectural reviews and lending a hand designing applications our team helps out with. I had the opportunity this week to see a great architecture and project plan, as well as to see one of the worst architectures and projects plans I have ever seen.
The good review was a pleasant walk through of design artifacts and proof of concept findings. Time lines were based on tasks and the efforts that were going to take place to complete them. It is a very larger system, with a tons of moving parts, and every one of those moving parts went through a proof of concept. If I was a betting man, I'd say there is a 98% chance of successful delivery. On time, within budget, bug free, well documented, and fully functional.
The other project was just nuts. It has been determined on high that this application will be done with a timeframe that is simply silly. There are 2 teams, one building the admin piece, the other the public facing UI.
The admin team was at least honest. They told us, "there will be no time for requirements gathering, analysis, or design, due to the timeframes. We will move directly to coding."
The other team has opted to use the old, "not a problem, we'll build this one with agile practices. We don't need use cases or requirements when we build with agile practices".
In this case politics are driving the deadline, and no one on the development team has access to speak to the people who made that decision. It would not do any good anyway. It was the old, "if you go electronic, you will save millions" feather in the hat promise. Well this is another one of those cases, and I have seen plenty, were they will make the deadline but it will be fake. So the paper process will begin to shut down in anticipation of this application arriving.
Then to every ones surprise, the new application will start having a few problems. There will be no design to turn to, so more developers will be hired and crazy hours of desperate programming will start to depreciate the quality of the system until the paper process is brought back online. The system will then endure a year of maintenance hacking with a team larger than the one that builds it, and in the long run we will spend 3 to 5 times more collecting the data this year. Two times on the paper process because it will cost to take it down, and then cost to get it up, and the rest on an application that did nothing but create a newly needed budget for next year.
So what do you do in this second case? You simply refuse to skip the proper architecture, proof-of-concept, and design phases. The people in charge don't know any better, but we should. Using deadlines as an excuse to skip doing proper architecture and design is just that, an excuse. It is not a reason. In the case above the wasted money is not the fault of the deadline setting politician, it is all the fault of the development teams. They are allowing time to determine the result instead of using time to manage the result.
The only real deadline is determined by the process and the completion of the artifacts determined by the process. If the process determines that a deadline set outside of the process is flawed, then it is not a real deadline and therefore any deliverable associated with that deadline will not be a real deliverable, it will be the delusion of a real deliverable.
It is a 6 to 7 month long time frame for the first build. The project was broken into about 20 iterations. There was an extensive proof of concept done to determine the amount of time it was going to take to finish the first release. The first release will be the baseline repository that will allow additional library data to be added in short release time frames.
When determining the time it would take for each content building iteration I had to set the timeframes as hard stops. If I didn't, I could probably spend months on each content library and still feel like I could do better. The time frame set was 1 week per content library. Content is coming from SEI, Microsoft, books, tools, and websites.
OK, so what? Notice I didn't say the iteration's timeframes were set based on budget, they were set by the amount of content we considered to be enough for our first release. In an application, this would be when a module is 100% complete, tested, bug free, documented, and integrated into the application.
This development process is doing with time what any project should do with time. It is being used to help manage the project, but it is not determining when the project will be completed. Time has absolutely nothing to do with the completion of a project unless we allow it to. Yet it is one of the most determining factors that we allow to mess up a good project. We all know why this happens most of the time, budget or politics. Sometimes it is just poor planning, no proof of concepts done to determine real time frames, and promises made on guess-tamations.
Some of the brightest dumbest people I have had the pleasure of working with are living in a delusion that they can control a project's creation with willpower and authority because they have decided there is a deadline that must be met because of budget or politics.
The rest of us know the deadline simply won't be met, but we also know they can't be convinced of that. If it is met, it is always a fake deliverable. Meaning the deliverable was delivered, the check was cut, the party was thrown, and a maintenance contract costing 3 times the original contract cost was signed to get the deliverable running over the next several months or years.
My responsibilities also include architectural reviews and lending a hand designing applications our team helps out with. I had the opportunity this week to see a great architecture and project plan, as well as to see one of the worst architectures and projects plans I have ever seen.
The good review was a pleasant walk through of design artifacts and proof of concept findings. Time lines were based on tasks and the efforts that were going to take place to complete them. It is a very larger system, with a tons of moving parts, and every one of those moving parts went through a proof of concept. If I was a betting man, I'd say there is a 98% chance of successful delivery. On time, within budget, bug free, well documented, and fully functional.
The other project was just nuts. It has been determined on high that this application will be done with a timeframe that is simply silly. There are 2 teams, one building the admin piece, the other the public facing UI.
The admin team was at least honest. They told us, "there will be no time for requirements gathering, analysis, or design, due to the timeframes. We will move directly to coding."
The other team has opted to use the old, "not a problem, we'll build this one with agile practices. We don't need use cases or requirements when we build with agile practices".
In this case politics are driving the deadline, and no one on the development team has access to speak to the people who made that decision. It would not do any good anyway. It was the old, "if you go electronic, you will save millions" feather in the hat promise. Well this is another one of those cases, and I have seen plenty, were they will make the deadline but it will be fake. So the paper process will begin to shut down in anticipation of this application arriving.
Then to every ones surprise, the new application will start having a few problems. There will be no design to turn to, so more developers will be hired and crazy hours of desperate programming will start to depreciate the quality of the system until the paper process is brought back online. The system will then endure a year of maintenance hacking with a team larger than the one that builds it, and in the long run we will spend 3 to 5 times more collecting the data this year. Two times on the paper process because it will cost to take it down, and then cost to get it up, and the rest on an application that did nothing but create a newly needed budget for next year.
So what do you do in this second case? You simply refuse to skip the proper architecture, proof-of-concept, and design phases. The people in charge don't know any better, but we should. Using deadlines as an excuse to skip doing proper architecture and design is just that, an excuse. It is not a reason. In the case above the wasted money is not the fault of the deadline setting politician, it is all the fault of the development teams. They are allowing time to determine the result instead of using time to manage the result.
The only real deadline is determined by the process and the completion of the artifacts determined by the process. If the process determines that a deadline set outside of the process is flawed, then it is not a real deadline and therefore any deliverable associated with that deadline will not be a real deliverable, it will be the delusion of a real deliverable.
posted by tadanderson at 9:27 AM
0 Comments:
Post a Comment
<< Home