Several years ago a client of ours was on a collision course with a brick wall while developing a new product. As usual the project was 6 months behind schedule, the client’s customer was extremely unhappy with no delivery and no one had had confidence that the project would be complete at all.
That is when I was hired. Fortunately I had worked with this client before so I knew who really knew what was going on. I was able to obtain copies of the specifications and project schedules. As expected both were incomplete. The project schedule was based upon delivery dates not the actual level of effort to perform the individual tasks. I asked management what leeway I had to effect changes. Quite a bit, actually, as long as the project was completed “successfully”.
I gathered the development team around and asked why is the project where it is. There were so many reasons but the main thread was that no one knew exactly what was expected of each and none believed or bought into the published schedules. Of course the requirements specification was weak, aren’t they always, but surprisingly the team seemed to have a pretty good idea of what the product was supposed to do. They also wanted to succeed.
Following a review of the documentation, code base and the issues stated by the development team, I was able to formulate an approach not yet a project plan. I recommended to management that all software development stop immediately. That we needed to complete the requirements definition ASAP, get management buy-in and then focus on the architecture. Fortunately the underlying technology was not an issue. Once those two items were taken care of we could produce a new schedule with buy-in from each developer. I was also able to determine if we had the right mix of skill levels. I noticed we needed a senior DB designer and a Software Quality Assurance person to be embedded in the team. Management was agreeable.
Finally the personnel were in place and a new project plan was published. Not exactly the dates management wanted but they were prepared to give us a chance to prove the turnaround. A key component of the new schedule was demonstrable milestones that could be shown to management and to their customer to gauge progress. I believe that was essential in management’s decision to approve the schedule. So how did we do? Well, there were many bumps in the road but the process was transparent so we could address issues early. The product was ready for delivery very close to the schedule’s published delivery date and the end-user was NOT ready. Finally the product was installed and turned over to the end-user.
Then I took a vacation!
That is when I was hired. Fortunately I had worked with this client before so I knew who really knew what was going on. I was able to obtain copies of the specifications and project schedules. As expected both were incomplete. The project schedule was based upon delivery dates not the actual level of effort to perform the individual tasks. I asked management what leeway I had to effect changes. Quite a bit, actually, as long as the project was completed “successfully”.
I gathered the development team around and asked why is the project where it is. There were so many reasons but the main thread was that no one knew exactly what was expected of each and none believed or bought into the published schedules. Of course the requirements specification was weak, aren’t they always, but surprisingly the team seemed to have a pretty good idea of what the product was supposed to do. They also wanted to succeed.
Following a review of the documentation, code base and the issues stated by the development team, I was able to formulate an approach not yet a project plan. I recommended to management that all software development stop immediately. That we needed to complete the requirements definition ASAP, get management buy-in and then focus on the architecture. Fortunately the underlying technology was not an issue. Once those two items were taken care of we could produce a new schedule with buy-in from each developer. I was also able to determine if we had the right mix of skill levels. I noticed we needed a senior DB designer and a Software Quality Assurance person to be embedded in the team. Management was agreeable.
Finally the personnel were in place and a new project plan was published. Not exactly the dates management wanted but they were prepared to give us a chance to prove the turnaround. A key component of the new schedule was demonstrable milestones that could be shown to management and to their customer to gauge progress. I believe that was essential in management’s decision to approve the schedule. So how did we do? Well, there were many bumps in the road but the process was transparent so we could address issues early. The product was ready for delivery very close to the schedule’s published delivery date and the end-user was NOT ready. Finally the product was installed and turned over to the end-user.
Then I took a vacation!
No comments:
Post a Comment