I loved Kimberly’s blog entry of Jan 14. Why do we keep making the same mistakes on every project? Why is it that we can write the “lessons learned” even before the project has begun?
The Lessons Learned list is familiar: key process components were missing, requirements were unclear, too many requirements changed, requirements were changed or added too late, the change control process was circumvented, issues didn’t get resolved quickly enough.
Each of these has a mitigation strategy that could prevent it from happening next time, and I’m sure they’re all part of Kimberly’s training course as they’re part of mine.
But I have some lessons learned from my past that are a little tougher, a little touchier, because they speak to an organizational root problem, as Paul suggested in his Jan 17 comment.
I know that one of the basic PM rules is that you have to expect that the task is “reasonable and rational”, but let’s explore anyway, because there’s “reasonable and rational” and then there’s reality.
Here is one post mortem “lesson learned” from a past project: Project began with too few resources.
Here’s the back story:
Another project hadn’t yet finished (it was woefully behind schedule), and the new project was bid assuming those resources. The assumptions given by Engineering for their cost/schedule estimate included this risk, but: what do you do? It was felt at the time that hiring new engineers or even contractors was not possible because you bid the experience of a specific team. An ISV (independent software vendor) would possibly delay the project start. But in a contract/bid situation where the customer is expecting you to meet your committed delivery date and doesn’t care about another’s project, delaying the start is rarely an option: even though a slip in the schedule is inevitable.
Other issues: If the customer knew that the project was in trouble this early, the project might have been terminated. But the customer should have known because spending on the contract was visible to them.
The General Manager did not have a project management background. He didn’t want to hear about something that was going to affect the project in a year or two. He couldn’t believe that “someone could anticipate that a lack of developers now is really going to affect an end date that’s 2 years from now”. He called it a CYA strategy.
What would you have done? Has anyone else had this experience? Anyone have another tough lesson learned?
