For the past three months, Tom had been leading a large consumer portal project that didn't finish too well.
|
How Project Managers Can Demonstrate Business Acumen on Every ProjectbyBusiness acumen isn’t just something that executives or other higher-ups have—it’s a skill that project managers can access and exhibit on a regular basis and within each project, no matter the size of the endeavor or type of industry. |
|
Conscious Unbossing: Career Choice or Leadership Philosophy?byConscious unbossing as a professional’s career choice and conscious unbossing as a leadership philosophy not only have no intersection, but can be detrimental in implementation. When does it become reckless leadership? |
Celebrate World Environment Day With Our Global CommunitybyJoin us on 4 June as we come together with project professionals, sustainability leaders, and volunteer voices from around the world for a special World Environment Day event focused on the future of project leadership. |
"I guess we committed a fatal sin of trying to achieve too much with emerging and untested technology," he said, "and we didn't sufficiently plan for the eventuality that our dot-com clients would run out of money, forcing the clients to eventually call off the project."
"What happened?" I asked.
"Well, to put it in a nutshell, we underestimated the time and effort it would have taken to work the particular technology we used. We missed most of the delivery milestones, delivering the project about a month late. That delay was enough to make our clients miss the window for further funding. Without the vital infusion of cash, they ran out of money and closed the project down. But I'm also proud of the fact that when the project ended, we didn't just go away to wallow in our tears. We made the effort to have a postmortem meeting to learn from our experiences and to use that knowledge to build a foundation for future successes," Tom remembered with a smile.
A lot of things went wrong on Tom's project, but a lot of other things worked out well. When the project goes sour, it's natural to have bruised egos, self-doubt and low levels of self-confidence. It's easy to want to put the bad experience behind you and move on. But it's important to insist on having postmortem meetings so your team members can discuss their experiences candidly and objectively, to review what went wrong and what went right, and to apply the lessons learned to future projects. If you do your postmortem meeting after every single project, you will have more knowledge of your projects--and gain more value out of it.
Here is a guide to getting the most out of postmortem meetings:
Do it right after the project is over
Most project managers recommend having postmortem meetings anywhere from three days to three weeks after the project. In my experience, the right time is just after the project is over. Especially in Internet projects, your teams usually won't have the benefit of taking a break before starting on a new project. This means that you have to get hold of them before they rush off to another project or leave on a well-earned vacation. On large and long projects, you might even consider conducting mini-postmortems after each milestone, so you can put into practice what you've learned as soon as possible.
Don't look for scapegoats
Keep the meetings positive and constructive. You're looking to learn from your experiences, not to find someone to blame for project failures. Although you will have to objectively confront the low points of your project, remember that postmortems are meant to be a learning experience to help you do a better job in the future, not an opportunity to trash your colleagues (no matter how tempting it might be).
Refresh on what you wanted to achieve and what actually happened
Begin the review meetings by refreshing everyone on what you initially envisioned the project to be and how you thought things would turn out. It would be helpful to include your schedule, milestones, budget and effort estimates. Then compare that with what actually happened on your project. Think of your project in playback mode. When and what were the major highlights?
"The functional requirements were a moving target," Tom continued. "Both the clients and our team had a clear vision of what we wanted to achieve. But we didn't have a clear idea of what we had to build, what functionalities we had to provide and how we would do it. The clients could only decide what functionality they wanted after having seen our prototypes. And prototyping put an additional strain on the schedule because we were still playing with prototypes when we should have already started working on developing a production version of the application.
"We delivered our deliverables late, and the closer we got to the deadline, the more features we kept leaving out. We ended up with a product that worked, but only provided about 40 percent of functionality. The VCs didn't like it, and the rest is history."
Where did it go wrong?
What difficulties were encountered? What assumptions proved incorrect? Where were targets missed? Tom's team focused on things that turned out worse than expected, especially unexpected problems that crept up. Mistakes always seem clearer in hindsight. They committed three fundamental mistakes: not demanding clearer specifications before beginning work; giving work to developers before specifications were written in stone, hoping to wing it and build things as they progressed deeper into the project; and selling a great concept without the skills and experience to build it. "I'll make sure we won't commit these errors on the next project," Tom said forcefully.
Where did it go right?
What went right with your project? Where did you beat your estimates? "In my project, we had a very smooth communications plan," Tom said. "I knew that my role wasn't to make people work, but to enable them to work. This meant asking my people all the right questions, and giving them all the right answers and tools to allow them to finish their tasks. As a result I spent a great deal of time communicating the hell out of my e-mail program, making sure that everyone understood what they had to do. But I believed that extra time was well spent, as I'm sure we would have wasted more time if I had kept quiet and hoped that people would gloss over problematic questions or try to wing it. We also discovered that ICQ turned out to be a great business collaboration tool--and not just a toy for lonely hearts--for those simple one-liner questions, or to collaborate with our external freelancers."
Review your risk plans
Did you take big risks, or did you play it safe? Did any unpredicted risks come into the picture? How did you resolve them? Evaluate your risk management experience and pay particular attention to how you would change your approach for the next project. Tom's team didn't handle the risk so well in the project. "We took a big chance on cutting-edge technology, and while the concept was good, we made too many assumptions and were overly optimistic in our chances of delivering a finished product on time." Risk is a two-sided dilemma: You have to show optimism to your clients, that you can do the job better than anyone else, but you also have to be truthfully pessimistic to yourself and recognize that there are sometimes limits to what you can achieve.
Did we manage for change?
Did any unanticipated changes occur in the project? How did you respond to them? Did your project suffer from excessive feature creep? "We had to draw a very fine line between giving our clients what they wanted, and preventing feature creep," Tom said. "Our client only knew what features they wanted after they had seen it. So, existing features mutated often into totally new features because customer focus groups dictated so. It was hard to freeze the feature set, and correspondingly, to manage change requests effectively because we kept arguing over what constituted a change request and what did not."
Review performance of team members
Human Resources might freak out at this, but I believe that mini performance reviews right after a project are the way to go, instead of those annual reviews. I recommend keeping these reviews on a private, one-on-one basis. When you have the opportunity to assess and improve performance on a mini-cyclical basis, you have a better chance of making change where it is most effective, right after the project is over when successes and mistakes are still fresh in the mind. Reviews have to go both ways, however. As a project manager, did you give sufficient information and resources? Did the team members perform as requested?
Act on your conclusions
Don't make all the effort in getting people together and documenting experiences go to waste by archiving the document at the bottom of a dusty drawer (or 10 layers deep in a cryptically named folder on your hard drive) and then forgetting about it. Turn your newfound knowledge into an action plan to feed back into your project processes and methodologies. Put the results of your postmortem up on your intranet where everybody can get access to them, or stick them up on the wall next to the coffee machine and in your team areas. You want maximum visibility here, and your aim is to drive the message deep into the minds of your team.
Postmortems are actually a very gratifying way to close a project as you can discuss and document all the personal and professional growth you've experienced on the project. And best of all, you'll help yourself from being condemned to repeat the past.
Geoff is a digital content strategist based in Italy. With more than five years experience in e-business consulting, project management and web development, Geoff helps clients navigate the maze of digital content development by defining, articulating, managing and implementing content and editorial strategies. He has previously worked as a project manager and web developer for IconMedialab and Collective Wisdom. He can be reached at [email protected].
|
"How far that little candle throws his beams! So shines a good deed in a weary world." - William Shakespeare |
