Do we really need a Project Charter in Software Applications Development?

In a small shop, creating an app for in-house use, requested by the owner, possibly not. But, whenever an expenditure of assets or resources is required, there should be some document authorizing those expenditures & the reason for making the expenditures. The charter is external to the project & defines the project in terms of the customer's business needs or market demand. It's usually created by the project's sponsor or initiator. This could be entirely internal, or it could be partially external, as in the decision to respond to an RFP, or it could be completely external, as in the case of fulfilling a contract. Being a PMP, I use the term Project Charter, but the name of the document is not as important as the elements it contains & the purpose it serves.

The Project Charter documents the requirements & the new product, service or result that will satisfy those requirements. It is the definition of the project, agreed to by all the initiators of the project. The basis for the charter may be a contract or statement of work. That document should contain at least:

1. The client's requirements & business needs
2. The project's purpose &/or justification
3. The PM & authority level to spend or acquire resources
4. Summary Milestone schedule if necessary
5. Identification of stakeholders & their influences
6. Functional organizations & their involvement
7. Assumptions
8. Constraints
9. The Business Case & summary budget

In my experience, except in the case of external contracts, I've rarely had a document that contained all of the above, but in the absence of any of this information, the first thing to do is try & obtain whatever is missing, & obtain it in writing. Much of the necessary information, even if contained in the authorizing document, must be elaborated anyway, especially in the case of 'legally required provisions' not explicitly defined in the document. If the equivalent of the project charter is a set of other documents providing essentially the same functionality as a Project Charter, it's not a bad idea to collect all of these documents & create a Project Charter, with the original documents as attachments, for the project sponsor to sign. There are numerous Project Charter templates & examples available on the net . Alternatively, if there is an electronic workspace for the project available, copies of the documents can be stored there, under a Project Charter Folder.

(As an aside, a common, accessible, project workspace is an invaluable asset, because it can contain up to date documents on all facets of the project. In Lotus Notes or other similar work group applications, a Project Conference, or document within a Projects Conference, can be a common accessible place to either put project documents or links to project documents.)

The client's requirements & business needs

I'm reminded of the Dilbert cartoon where the Project Manager asks " What do you want the software to do?", & the response is "Tell me what you can make it do". In the absence of requirements, how do you know what product or service to provide? So let's assume you will have at least a high level definition of the requirements. Without a definition of the business needs, both you & the customer may be solving the wrong problem. An analysis of the business needs can also help in prioritizing & phasing the project, & especially in defining the deliverables.

The project's purpose &/or justification

This might seem to be the same thing as the business needs, but it's more related to the reason, rather than the need. There might be plenty of projects that fulfill some requirements & business needs, but are not in line with the organization's business strategy or whose justification is not in line with company policy or vision. For instance, the software requirement might be to
change a numbering scheme for identification of particular objects in a drawing application. There is a business need because newly obtained customers switched over from a competitor are used to this different numbering scheme & are demanding it. The requirements are defined & so are the business needs, but the purpose is not to provide the new capability, it is to increase new customers comfort level with the software.

The Project Manager & authority level to spend or acquire resources

Hello! This is your project. You can spend up to ? ($, hours, ...). You can have ? resources. Hahaha! More likely, you will be given authority to spend just enough in time, money & resources to initiate the project & set up the project plan including the prospective budget & resource requirements. But, at the very least, you can begin the process. The most important thing is that this is where the Project Manager is named & is given responsibility for the Project. From this point on, the conduct & outcome of the project belongs to a single individual & point of contact.

Summary Milestone schedule

If there are contractual milestones, or immovable dates ( e.g. a trade show or Federal reporting deadline), these should be spelled out. These milestones are customer, legal or organizational in nature & are not subject to slip or negotiation. Other milestones may be developed as part of the project plan but those are plan driven, not requirements driven.

Identification of stakeholders & their influences

The Project Manager's main obligation is to get the job done, but most of the work done by the PM is communication. Stakeholders are anyone who can influence or be influenced by the project. Whether sponsor, customer, team members, other functional managers, supervisors, vendors, or the public. The Charter spells out, at the very least, the stakeholders from the customer & sponsor's point of view. Additional stakeholders will be identified by the PM
during an analysis of the Project, but the stakeholders spelled out in the Charter are likely to be the ones most interested in the project's success.

Identification of the functional organizations & their involvement

Most of us work in a balanced matrix environment. If our software project will require resources or input from other departments or organizations, we’ll need to know who they are, & what contribution to the project they will make. We might need contract specialists, engineers, facilities people, etc… If these other departments’ involvement is required, they need to be specified. If their involvement is not required by the contract or explicit in the charter that does not mean that these dependencies don’t exist, only that they will need to be identified later
on in the planning process. The charter should at least provide authority to acquire resources from other functional organizations as required.

Assumptions

Assumptions may involve the availability of resources, technology, access to the customer/end user, facilities, knowledge, funding, etc…. All assumptions carry a degree of risk based on their likelihood of being true. Assumptions explicitly documented in a project charter must be treated as true, real or certain. If these assumptions are agreed to and signed off on, they form a contract which can then be used as the basis for planning. Even so, they must be listed on the risk register, even with a low percentage of likelihood, since their impact can be considerable.

Constraints

Both constraints & assumptions limit the team’s options for resources, staff, scope & schedule. If there are contractual constraints like defined delivery dates, budget considerations, buy vs. build specifications, lists of acceptable vendors or products, minimum requirements, performance penalties, reporting requirements & dates, etc… these should be documented & agreed upon up
front. There are always constraints & if your initiating document does not contain them, you should determine them as soon as possible & get them documented. No one has access to unlimited funds, staff, facilities & time.

The Business Case & summary budget

The Business Case deals with ROI or the perceived benefit to the company measured against the costs or risks associated with the project. It is usually done before the project is given the go ahead & is based on the project getting done for a cost not to exceed that calculated during the analysis of the project by its sponsors or initiators. Usually, alternatives have been analyzed as well and may be listed along with the reasons this project approach was chosen rather than the alternative. In any case, the business case & summary budget provide both the framework &
the context for the project. In my own experience, I seldom see the business case, but I often see the summary budget, which becomes one of the primary constraints. Indeed, after I do my own budget for the project, comparing it to the summary budget brings the risks associated with the project into greater focus & leads to later go – no go decisions. The business case should be revisited by the sponsor, organization & customer at regular intervals to ensure that it is still valid, & even though this is not a PM function, it certainly impact the project.

Summary

The charter is the first document the PM sees. It defines the project’s goals & rationale. It sets the limits & identifies the players. I’d hate to start a project without that information.