A project is born. Say what, sounds like we're talking about a baby. Whose kid is it anyway? I mean, whose project is it anyway and when was it born? I can't tell if it's a big baby or a small one; I mean a big project or a small one. Oh yes, we are really talking about the birth of a project. Let's start with defining a project so that we have a better footing as to purpose of this thing we call Project Initiation. The doctrinal response to defining a project is: "It's a temporary group activity designed to produce a unique product, service or result." The definition further establishes that it (project) has a defined beginning and end time. (Project Management Institute: A Guide to the Project Management Body of Knowledge (PMBOK® Guide) - 2013, Fifth Edition, Page 2)
Just as a clarification of the above reference book, the Project Management Institute's: A Guide to the Project Management Body of Knowledge (aka, the PMBOK), contains the accepted industry standard for project and program methodology. The U.S. Department of Defense (DOD) also has its own PMBOK that is inclusive of the PMI published content and additional information tailored to DOD requirements and procedures. Additional, for those that might be interested, the is also a U.S. Department of Defense, Extension to: A Guide to the Project Management Body of Knowledge, Published by the Defense Acquisition University Press, Fort Belvoir, Virginia 22060-5565 (DoD-Ext.PMBOK)
The birth of a project is more than a singular action or effort. Initiating a project is a mental and academic exercise incorporating information collecting, evaluating, and decision making as to whether a project is the solution. This exercise includes defining how the project's outcome of a product or service will satisfy the business need; how it fits into the individual's or organization's strategic plan; define the criteria in selecting the project, product or service; are there any (and usually will be) historical perspective from other projects that may aid in decision making on if and what this project will be.
Whether the proponent of the potential project is an individual, organization such as a business, government, military, charity, sports team, or church body, just to name a few, the fundamental questions come down to: what is our situation; what are the circumstances and conditions driving our situation; and what is our desired end-state. Some of the usual reasons for starting a project include market demand, customer request, technology advancement, legal or regulatory requirement, and new product design or development. After thoroughly investigating and analyzing the collective information, the individual or organization evaluates project selection methods, perform decision making [link] to determine and identify the desired end-state that will further drive the basis of the project.
Remember, projects come in all sizes: designing a new product, building a house, catering a party, installing new services for a client, designing or providing training for a group, or anything that meets the definition of: it has a defined start, a defined outcome of a product(s) or service(s), and a planned end date and end-state (what does "done" look like: Scope).
Outcome of Project Initiation
The result of project initiation is the formal recognition and defining of a new project or that an existing project should move to its next phase. It is not unusual for there to be a phase to phase signoff process whereby the project sponsor/contract authority signs-off approving all the work completed to date and allowing the next phase (the next phase new project) to move forward. A Project Charter is the vehicle used to document and "formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities." (PMBOK Page 62)
The Project Charter
- What's in it?At the least include the following information: name of the project; an initial scope statement; name/assign the project manager (PM); define the PM's role and responsibilities; provide initial risk, constraints (includes initial financial resources), and assumptions. Notate the internal and external stakeholders who will interact and influence the overall outcome of the project. These stakeholders may include the project team (if the team has not been assigned yet, then a simple reference to "The Project Team" is sufficient). The sponsor or source for the authority of the project is named and signs/dates the charter.
- Who develops and writes the charter? It should be the business/organization's brain trust and the sponsor that decided to create the project; however, more often than not, it is the PM and the project team that assemble the charter after the fact of the sponsor/leadership's decision making process. The PM/Team collects up all the pertinent data and assembles the charter with the information they need and submit it to the sponsor/contract manager for signature.
- Business Need: Describe: It can be a problem statement or improvement need statement of a strategic importance to the company such as a newer more competitive product; it may be a need for a new process, it can be regarding a new construction project. It must at the least be a fundamental description of why this project is being pursued. What is driving the effort? Below are some of the background subcategories that can be included; however, the sponsor and the PM should include other subcategories as needed.
- Project selection criteria: This is especially important when a project is to develop or may need to develop multiple product or service options for further consideration.
- Feasibility Studies: This may only be a general comment followed by a reference to another more detailed "Feasibility Studies Report" assembled by the sponsor of the project. The study can be useful to the PM and the team in ensuring that the project results/output product or service doable for the company/business/government agency.
- Project General Description: These are characteristics of the product or service with high level requirements; a statement of the scope in general terms. This statement is often followed up by referencing the reader/PM/Team to a Design Specifications Document.
- Name the Project Sponsor/Contract Authority: This is the person with the authority to name and further authorize the PM to lead and manage the project effort. Include the sponsor's position and a line or block for the sponsor to sign-off as approving the Charter.
- Assign The Project Manager: Assign the PM as soon as possible, his/her role, the individual PM's responsibilities, level of authority, mechanism for status reporting, reference to project policies, procedures and financial management requirements. Many businesses have a published organization wide set of standard requirements that spells out the PM/Team responsibilities. If this is the case, a business may simply notate that the PM/Team will provide and reporting in accordance with the company's project standard operating procedures (SOP) document (include reference to the specific page or section of the SOP.
- Project Manager Authority and Responsibilities: Who is in charge of the project and what are his/her authority and responsibilities. This may be a simple authority statement with a reference to a corporate or organization's SOP.
- Risk: It's true that there will be risk throughout the project but there are some risk items that can be identified by the proponents or sponsor(s) of the project at the outset. Sometimes these are issues tied to the assumptions explained in the previous paragraph. In other cases, they may be tied to constraints; they will be covered in the next paragraph. Risk issues or items are those things that may, if they occur, affect the project either good or bad. Yes, that's right, even good. For example, if a business decides to try and create a new more competitive product and funds are limited to the project; however, there are some talks with a potential investor that could bolster the available project funds: that is a positive risk item. For the PM, it means that he/she may need to be prepared for expanding the project scope. Or, on the down side, the new investor drops out, other current investors drop out and funds become too tight to continue supporting the project, thus requiring the PM to kill the project and moth-ball the work completed to date.
Remember, there will be plenty of other risk items that will be identified through the planning and execution of the project. In fact, the risk identification and management of same will continue through till the completion of the project. Some quick and easy risk items include: the start date may move; the end date may move; funding may be reduced or cut; additional funding may be available during the business budget review cycle; the might be the potential of a loss of key team members; there may be a concern as to the potential unavailability of material or equipment resources when they are need. These are just a few of the more obvious types of risk issues.
Careful identify and document any potential risk items that have to be either, planned for through contingency planning, or at the least, kept in the back-of-the mind by the PM and the team: you know, those just in case type of things. I'll talk more on Project Risk in another article.
Constraints: Look back at your risk items and determine whether or not some of these may also create constraints on the project. You should have established a baseline budget for the project and you may have already worked in some variance allowances such as a baseline budget of $500,000 with a variance of no more than 10 percent if funds are available; or, there it may be a max ceiling of $500,000 period end of discussion. Project and product specifications can be constraints if they are, for a lack or a better term or phrase, "do or die" requirements. Resources can be constraints. Let's say that the organization feels that they cannot provide internal expertise or team members and or equipment, this will require the PM to find the team and the resources from outside the organization and, somehow, he/she will need to work with the sponsor on funding the staffing unless the fixed budget is inclusive of all support requirements. A $500,000 budget will not go far in that case. A PM or organization, especially in government, may be required to use only certain vendors. This too will create a constraint and potential risk of availability.
Assumptions: Factors that are considered to be true for the purpose of moving forward. As we all know, there are a lot of unknowns in business (and in government and the military). We assume we are going to get paid for our work and we assume that the car will start before work and we assume that we will wake up in the morning. However, all these events are not facts until proven or occur. We assume that the project will have all the budgeted funds for the full duration of the project - but it is not a fact until we reach the end, and then, only after the contracts have all been paid up. Thus, we have our assumptions that we, for the sake moving forward, we treat as facts until proven otherwise.
Stakeholders: This is sometimes left out but is beneficial when establishing who can authorize contracts/funding for external resources such as contractors, as well as, naming those approved internal and external resources or interest/vested agents: for example, functional managers or other departments affected by the project.
Project Charter Example
[This is only a make believe example. It is also not a limitation to what can be in a project charter.]
Military/Business Need: Warfighting in the 21st century requires economy of force with weapons systems that are universally adaptable to all branches of the military. Over these past several decades weapons, equipment and vehicles have become more complex, expensive and less versatile. Every branch of the military is scaling-down in numbers of personnel and equipment. In order to maintain the ability to react quickly to threats, in the most effective way, within the limits of our current and future warfighting resources, we need to pursue various unmanned weapon systems and weapon systems that will maximize the ability of a small force to conduct successful military action against a larger enemy force. The first step will be to develop an unmanned ground assault vehicle that can be remotely operated in a manner similar to that of the current unmanned drone.
Project Description: Design and create a working prototype of an unmanned ground assault vehicle that incorporates the design specifications/mission essential capabilities as outlined in the Detailed Specifications Document (restricted).
Project Sponsor: U. S. Grant, General, U.S. Army: Signed/Dated _________________
Contract Authority: G. A. Custer, Colonel, U.S. Army: Signed/Dated ______________
Project Manager (PM): Ima Grate, PMP; date assigned 1 February 2014.
- PM Responsible for ensuring all key milestones and objectives are met within the time, cost, performance and quality constraints of this project. PM is authorized to hire additional personnel resources in addition to the DOD provided team and manage all aspects of the project and issue appropriate directives as pertinent to the project.
Constraints: Planned Budget = $4.5 million; Deadline for design model (concept model) is Apr 2015; Prototype completion date 15 October, 2016 with live fire demonstration test date of 15 November, 2016. Other constraints are listed in the Design Specification Document. Other: list other restrictions…..
Risk: Annual and semi-annual budget reviews may require revision of the planned budget. Other: listed…..
Assumptions: Design, development and prototype construction and testing are independent of current world threat events. Other: listed…..
Stakeholders: Listed in separate appendix.... Review, reference, or enter stakeholder date as shown in the Project Charter.
The beginning of the project determines the outcome of the project. Let’s face it; if you have unclear requirements, customer expectations, a lack of commitment from all the stakeholders, or no dedicated and supportive sponsor, you have the makings of a troubled project.
Do you know why many project managers and program manager’s refer to their offices or team rooms as “War-Rooms”? It’s because it is not unlike a military operations center or a tactical operations center. Sometimes leading and managing a project can seem like leading and managing a battlefield; there is a significant amount of reliance on information, cooperation and coordination.
A project manager and the team must have as much information as possible as to a clearly defined outcome, a desired end-state. They must know who’s sitting in their corner to aid in the accomplishment of the mission; and, they must know who their enemies or potential adversaries might be, to include risk, constraints and even assumptions. A bad start to a project or a military mission can spell a less than desired ending to the same. A bad start is one of the enemies to a successful project.
Note: I will be presenting an article dedicated the Project “War-Room” in the future. It will include a comparison between a civilian project and that of a military operation. Current and former military veterans should particularly benefit from understanding how their military experience directly relates to the role and tasks of a project manager, program manager, coordinator, or project administrator.