Welcome to the first week of the five week series on how to best use the Small Project Management Guide. Andrew Krzmarzick prepared a weekly question that highlights a part of the guide. This week’s question is about the project charter:
“Do you have an example of when a project team did NOT establish a project charter? What happened?”
Not having a formal project charter is common especially for small projects. What I have often seen is a list of requirements that are either verbally given to the project team who writes the requirements or the project customer prepares their own list. The project customer has in their mind a a reason for the project and a vague impression of what will solve the problem they are confronting. The project manager is briefly told about the problem but then everyone dives into the particulars of the project because we need that problem solved now. The list of requirements are often a substitute for the project charter. That doesn’t mean that the project will automatically fail but it often results in project products that don’t meet the customer’s needs or actually solve the problem in the first place.
Let me talk about a project from long ago because it seared into my mind the necessity of making sure the project will actually solve the problem and have value for the project customer.
I was the lead developer and project manager for a large project where our team was to convert 40+ Lotus Notes databases into ASP applications. The Lotus Notes databases were used by an oil company to handle various processes related to their oil refineries throughout the U.S. We had great success in delivering the first 18 applications and I was especially proud of one ASP application that I designed that handled all refinery engineering requests. The client was happy, the boss was happy, and the team was happy. The project didn’t have a formal charter but we knew what we had to do because the client just wanted the ASP applications to work just like the Lotus Notes databases they were replacing. No need to elaborate upon that simple requirement.
Then I turned to the next Lotus Notes database. It was quite simple and only had seven items in the database. Now that should have stopped me but, guided by the simple requirement and because I was doing what I was told to do, I went ahead and built an elaborate ASP application to sort, search, and display those seven items. It was a marvel of programming! I was ahead of schedule and the application worked flawlessly so I happily shipped this to the client. Two days later I was called into my supervisor’s office.
Earlier that day the client had called my supervisor asking what the hell was this thing I sent them. They were not going to pay for such a stupid application that only handled seven items that would be better off being put into a spreadsheet. No one was impressed that I had been ahead of schedule or that the application worked perfectly because I had built a solution that was way out of proportion for the problem to be solved. I was given the obligatory scolding and, for the remaining applications, we developed a set of guidelines to determine if we needed to build an ASP application or just seek a simpler solution.
This is why the first template of the Small Project Management Guide is the project charter. Before you start any project you need to determine what the project will actually deliver and if the project product actually solves the problem. That requires that the project customer and all the stakeholders actually agree on what the problem is. Spend time analyzing the problem because simple problems have a nasty tendency to become complicated very quickly. This is also the best time to decide if this problem is worth solving or does the organization need to concentrate on more pressing problems.
Once you have an understanding of the problem then you can concentrate on the project product. Please don’t just settle for the first solution. See if you can’t modify an existing solution first (modification projects are relatively easier to manage than building a solution from scratch). Have a brainstorming session to come up with at least three independent solutions to the problem. The best way to avoid a failed project or a project that doesn’t deliver the solution you wanted is to not start the project in the first place. Again, make sure all stakeholders agree that the project product will solve the problem. Always put this agreement in writing.
I also have you list your project customers in the project charter because they are the final judge on whether your project was successful or not. Too often, project managers focus on bringing the project in on schedule, on budget, and to the agreed scope. This is desirable but the real purpose of any project is to deliver a solution to the problem. There are numerous examples of projects that were way over-budget, very late, and didn’t fulfill scope. These projects were initially considered failures but because of their realized value they became quite successful as time passed. The Sydney Opera House in Australia is a great example of how project failure can turn to success.
The final part of the project charter is the project sponsor’s signature. As a project manager, you rarely have any formal authority. The most successful project managers use reputation power and persuasive power to get things done but it is vital that you have an executive in your corner that you can call on to help “push things along.” Don’t abuse this borrowed power because your continuing success as a project manager is the personal reputation you build.
The ultimate purpose of the project charter is to answer four fundamental questions:
- What is the problem that needs to be solved?
- Is this project the best solution to that problem?
- Who determines if the project product is a good solution?
- Does the organization support the project?
Next week we will discuss “Scope Creep” or how the road to project failure is paved with good suggestions. Thank you for the feedback on the Small Project Management Guide and I hope it has been useful to you.
Great post, Bill. I like your real-world ASP application example. Really helps to illustrate the need for a clear direction and purpose at the foundation of a project in order to successfully meet client needs. Also, thanks for all your work on the Guide itself. Great resource!
Actually, I kind of disagree with your diagnosis on the ASP project. The discussion with the sponsor concerning the charter seems right on. When I approach that process I look for:
I think you kind of hit those points, maybe not written down, but hit them nonetheless. However the progressive elaboration of the Charter is what should have happened by the Kickoff Meeting with the project stakeholders. It was at this point at which someone probably you, since you were the Technical Lead, should have gone through all of the Notes DBs and identified the next level of detailed work to the team. For example, you can’t have any idea how long it will take (schedule) until you pull back the curtain and take a look at the detailed databases. Then, if the team authorizes 40+ ASP DBs, at such and such a cost and schedule, then that is what gets built. In this case it would have likely turned into 40+ DBs and some number of spreadsheets. But in either case, I don’t think the charter was the pain point. I think it was the elaboration beyond the charter.
Also, for small projects, it may not be critical that you get a charter signed in blood. The important thing is that the stakeholders understand the aspects of the charter and support them. For example if you went through a project last year and after it is complete you embark on a similar project with the same team, you might not need a charter. Or, if the number of stakeholders is so small (like 3 or less) and the information from the sponsor is all primary information, then you are probably safe.
We need a charter when all of the stakeholders aren’t there when the sponsor paints that vision of the desired outcome. The charter is the authoritative
@Jeff – Thank you! Learn from my mistakes; I have plenty. 😉
@Tim – Thank you for your comments. I agree with your list of points for the charter which would be appropriate for a large project. With small projects, you often have new project managers and/or “accidental” project managers so I designed the charter to be as minimal as possible while capturing the essential decisions needed to justify the project and move it forward.
I fully agree with your analysis of what I should have done as laid out in the second paragraph. At the time of the project, I was an accidental project manager myself who was appointed because I was just starting an MBA in Project Management. When I started the project management courses, I realized my earlier mistakes and that is why I also sought certification. Two of the most important lessons I learned is that the PM process is iterative and that frequent communication with the stakeholders is vital.
But I must disagree with you on not needing a charter for small projects. I like President Reagan’s advice to “trust, but verify.” In this case, the charter is a communication tool because it compels the stakeholders to focus on defining the problem and to determine if the project is a good solution to the problem. Even if you are doing the same type of project on a continual basis, I would still require a charter for each one (even if it is a copy of a previous project). I’m a stickler for having everything in writing because I don’t trust my memory or other people’s memories and I would rather avoid arguments over who remembers what.
A major purpose of the Small Project Management Templates is as a teaching tool for beginning project managers. Some small projects may not require this much detail but I believe it is a useful exercise for the nascent project manager to learn the terminology and basic documents for project management.
Bill, your real life experience accords with my experience and hence my determination now to ensure a “charter” is captured so all parties (1, 1-4, 1-..) are on the same page regarding what the project is for and what is to be delivered.
Thank you for the PM booklet, I have passed this out to my new PM staff.
@Dean – Thank you! I would appreciate to hear the reaction from your new PM staff. The booklet is just start and I hope that your staff continues to learn about project management. I highly recommend that Wysocki’s Effective Project Management: Traditional, Agile, Extreme be the next book they read.