Many years ago I worked on a huge project to upgrade a complex mission planning system to new hardware and a new language. Our requirements were simple (I can hear chuckling now). Simply make the new system work just the way the old system worked. Oh, and don’t forget to improve performance as much as possible. Oh, and don’t forget to improve the user interface to make it easier to use. And, oh yes, if you are working on a module that has a defect against it go ahead and correct that defect if it won’t take too much time. And, finally, oh yes, make sure the project is completed on time.
So the management team spent months preparing for this project. They looked at all of the software involved. They looked at resources. They got estimates for the time required to rewrite each piece of code. They assigned priorities to each task. They looked at resources and scheduled resources for each task. They created a project schedule. They created a huge spider chart that covered two walls showing the relationship and order of the tasks. That spider chart was so impressive when you came into the area and saw it. I’m sure you would think “Wow, they have this project under control and well managed.” The ship was ready to sail.
The project was supposed to be completed in a year. Would you surprised if I told you we didn’t complete it in a year. I forgot to mention that we had no requirements for the previous system. We were just working off of things by actually running the old system to see what it did. We had a couple of expert users who were checking things as we went to make sure it was acceptable. They were actually our testing team as it turned out. So at the end of the year we were 99% complete according the project schedule, spider chart, and all of the other metrics. The problem was that those metrics were all based off assigned values by the worker bees. Things were shown to be complete that weren’t actually 100% complete – they were close. Reviews were shown as complete whenever the meeting was held regardless of the follow up activities that were required. So everything looked great on paper. We all knew that wasn’t true. The ship had hit the iceberg.
Another year went by and we worked very hard. We were told to work harder and work smarter. But no overtime. Just get the job finished. We all worked hard. We ran into all kinds of issues with the new hardware. The issues kept bubbling to the surface but no one was really in charge of addressing the issues so they languished. The expert users kept insisting on enhancements that had not been agreed to and because we had to real requirements we kept trying to please them. And often their requests were in conflict with each other and there was no one to resolve that conflict. We usually ended up in a room with a lot of shouting going on. At the end of the year guess what? We were 99% complete again. The ship had sunk.
Management went ballistic, as you can imagine. The project manager kept insisting we just weren’t coding fast enough. That we were over analyzing. That learning a new language had slowed us down. This may have been true but the real problem was that we had no requirements to work from or to go back to when changes were made. In my mind that project was the epitome of chaos. That third year was the worst year ever. We worked ten hours days, often six or seven days a week, with no extra pay. I think we all just wanted to get this project done and finished.
So my question to you is this? Does everything look good on paper for finishing your project on time? If so, take a deeper dive into the requirements and make sure they are clear and traceable. Make sure the team knows what they are trying to do and who to take direction from. I think of the expression that “too many cooks spoil the pot”. Too many users involved in the development effort without defining the real requirements can spoil the project. Saying you have completed every milestone without having the deliverables to back it up is just delaying the inevitable. Good luck in steering your ship to a successful completion.
No comments:
Post a Comment