Lessons Learned in Project Management: Part 1
True story: I once worked as a software developer for a wireless telephone provider in the mid-1990s. I was brought into a project planning session with representatives of several different development groups in the organization. The project was early in its definition phase, and it related to putting an end to a nasty problem where it was once easy to manipulate wireless phones to fraudulently bill someone else – a serious problem for wireless providers before they went completely digital.
As we started discussing the project from a high level, the various development groups began comparing what each of us could contribute to identifying a fraudulent call from a non-fraudulent customer. Things got technical quickly, as each of us tried to identify where in the call setup we could make that determination…or if it was even possible to make that determination.
We were all well on our way to speaking to each other in 1’s and 0’s when the project manager stopped us with the words, “I’m not interested in the technical aspects of the project, I just want to know if we’re going to make the schedule.”
All of us stopped in mid-sentence, stunned. Not only were we not aware that a schedule had already been prepared, but what we were trying to determine was if the project was even feasible.
Now, to be sure, this was an extreme example. And before any of you project managers out there get torches and pitchforks in hand, know that I, too, have worked as a project manager, I have the utmost respect for your position, and I know that this misguided individual is the exception not the norm. But this experience taught me several valuable lessons in how NOT to manage a project:
Give the team time to think – Let the project team explore the possibilities on their own. A good team will brainstorm all ideas and keep the bad ideas from entering a project design. A good project manager will make sure the design that emerges will sufficiently meet the requirements (that’s what design documents and design reviews are for).
Have faith in your team – The members of a project team are professionals. Let them do their job and you do yours.
Let the team have input on the schedule – In the case above, someone had already determined the project schedule before the team even sat down for the first meeting. Instead, the project team should be able to estimate the time required to meet the goals of the project before a schedule is prepared. The project manager should then hold the team members accountable for their estimates and be willing to challenge them if the estimates seem too long or too short.
Be prepared to complete the project in phases – It would be nice if everything took three weeks to build and had everything in it all at once, but that is just not practical. It is sometimes best to develop a complex project in phases. That gives the client the most essential functionality up front and in a time frame that is achievable. New functions can be added once the main framework has been developed.
And that wireless phone project? In the end, we did find a way to identify fraudulent calls and, together, the groups developed a method of stopping only those calls from completing. We also developed an aggressive, but achievable, schedule – in phases – and the product worked as designed. In the end, the project went on to save the wireless industry literally millions of dollars in lost revenue.
In part two, I will talk about what project teams can do to help their project managers.