Project management — Getting back to basics
Joseph A. Lukas, CSM, PE, CCP, PMP
Some project managers focus on completing project forms and checklists, and this bureaucratic approach can result in losing sight of what is really important, which is meeting the client's project objectives. What's needed is a renewed focus on getting back to basics with project management! This paper will provide a perspective on how to simplify projects, saving time and energy, while still doing the essentials needed to ensure project success.
The five key items that must be done on projects to ensure success will be covered. This paper will also explain how implementing a pragmatic project management methodology is the ‘suspension bridge’ to successful projects. The final topic is a tool called the Project Controls Index, which helps determine how much project management is needed for a project based on key criteria such as cost, duration, complexity, and risk.
An unfortunate situation is more client organizations pushing back on the discipline imposed by project management. The frequent complaint is that project management is too bureaucratic, requires too much planning with too many forms to complete and results in projects taking longer. Clients also complain about project schedules that are too detailed, which become very burdensome to update and difficult to follow. In addition, even with the use of project management and with active sponsors, 36% of projects do not meet their original goals and business intent (PMI, 2013a, p. 12).
These are all valid complaints, as some project managers get too engrossed in blindly following a process and lose sight of the bigger picture, which is meeting the project objectives for the client. What is needed is a renewed focus on getting back to basics with project management! The five basic items that must be done on all projects using a waterfall project life cycle will be covered in this paper. Without the ‘Fab Five’ being done correctly, a project is very likely to fail. Changes to the five basic items for projects using an Agile project life cycle will also be explained.
The first suspension bridge was the iron chain bridge at Jacob's Creek, in Westmoreland County, Pennsylvania, in 1801 (Suspension Bridge, 2002, ¶4). This ‘bridge to the future’ began a period of rapid development of the modern suspension bridge. This paper will discuss how implementing a pragmatic project management methodology is the ‘suspension bridge’ to a future of successful projects. Management support is the bridge foundation, and project procedures are equivalent to the bridge towers, providing the guidelines on how to do projects. The bridge deck is the project process, which is the road you follow to have a successful project. Templates are the suspender cables holding up the project process. A suspension bridge and project management only work if all of the key elements are in place!
Project organizations need to understand the basics that need to be done on all projects, and what project management processes are optional depending on the project. The final topic covered in this paper will be a key tool called the Project Controls Index. This tool provides a very effective method to decide how much project management is needed for each specific project based on key criteria such as cost, duration, complexity and risk. Think of it as having a toolbox. You don't use every tool on every project; the tools are there for use only when needed. The Project Controls Index helps the project manager determine what project management tools are needed for each specific project.
In summary, this paper will provide a perspective on how to simplify projects, saving time and energy, while still doing the essentials needed to help ensure project success.
Five Key Items Needed on All Projects
Listed below in Exhibit 1 are the five key items needed on all projects using a waterfall project life cycle. Having a Project Charter, project requirements, and a Work Breakdown Structure provides a solid foundation for project planning and communications. Pundits will undoubtedly argue that other items such as a change management process or risk management deserve to be on the list, but adding more and more items just reinforces the frequent complaint that project management is too bureaucratic, and requires too much planning with too many forms to complete. A project may not have any changes or any potential risk events. However, the five items below are needed on all projects. Without the ‘Fab Five’ being done (and correctly), a project is very likely to fail. In addition, project teams that excel with the five items below are probably capable of dealing with other project management subject areas such as changes and/or risk events if required.
A Project Charter is “a document issued by the project initiator or sponsor that formally recognizes the existence of a project…” (PMI, 2013b, p 553). The Project Charter is a concise document of one to a few pages, and may have some attachments such as a business case analysis and/or a feasibility study. Two key inputs needed to prepare the Project Charter are the business need for the project and the project alignment with the organization's strategic plan. That's why the Project Charter is one of the five key items needed on all projects; it ensures the project is creating value for the organization and the project team is not wasting their time! Without a Project Charter there is a very real risk of spending significant time and money on a project before the client organization realizes the business case is lacking and stops the project. In fact, “this lack of alignment of projects to organizational strategy most likely contributes to the surprising result that nearly one half of strategic initiatives (44 percent) are reported as unsuccessful” (PMI, 2014, p 5).
Unfortunately, many clients find multiple excuses for not preparing a Project Charter. In those cases, the project manager should take the initiative and work with the client to pull together the Project Charter. This includes developing quantitative success criteria for both the project and product. Project success criteria typically includes items such as cost, schedule, quality and functionality. Product success criteria can include items such as achieving specific planned benefits, user satisfaction and quantitative acceptance criteria. A Project Charter with success criteria helps ensure the right project is being done and allows the project team to help safeguard the business case over the life of the project.
A requirement is “a condition or capability needed by a stakeholder to solve a problem or achieve an objective” (IIBA, 2009, p 4). Requirements describe what is needed, and the project scope is how the project team will meet the requirements. Requirements are the foundation upon which the scope and project plan is developed, and if the requirements are incomplete and/or incorrect the rest of the project plan by default will also be incorrect.
Studies by multiple organizations, such as the Standish Group, indicate that a major reason for successful projects is well defined requirements; for challenged and failed projects the reason is poor, incomplete or a lack of clear requirements (Mieritz, 2012). A commissioned study conducted by Forrester Consulting with 150 business decision makers in product development looked at the most common problems during the development and delivery process (Forrester, 2013, p 4). Shown in Exhibit 2 are the results from this study. The top reason at 41% was the inability to agree on requirements due to conflicting priorities or opinions. The third highest reason at 29% was requirements not capturing what the customer needs.
A specific project example regarding the importance of requirements was a client who told the project manager space was needed for factory personnel to take coffee breaks and lunch. The proposed project was conversion of almost 900 square feet (SF) of available warehouse space into the needed dining area. The client explained the project should include microwave ovens, refrigerators, a sink, counter space, and tables with chairs. The client in this situation jumped directly from the business need (which is a business requirement) to project scope details. If the project manager had proceeded with this project it would have been a functional failure. What was missing were some very important project requirements, the most critical being how many factory personnel would use this new facility. Building codes establish the maximum occupancy for spaces such as dining areas and the 900 SF available space was woefully insufficient for the number of factory personnel. If built, the local building code authorities eventually would have discovered the violation and either shut down the dining area or greatly restricted how it was used. The result? It would have been a failed project due to incomplete requirements, but on this project the team was smart enough to engage the client in eliciting complete project requirements.
Work Breakdown Structure
The Work Breakdown Structure (WBS) defines the project scope in terms of deliverables, which are “any unique and verifiable product, result or capability to perform a service that is required to be produced to complete a process, phase or project” (PMI, 2013b, p. 537). Deliverables should be written as nouns and can be project related such as a requirements document, test plan, and project closeout checklist. Deliverables can also be product related such as a new server, new software application, and training class. The point is the WBS must define the entire project scope since it is the key input to other project management planning processes such as schedule, cost, resources, risk, procurement and quality. The WBS also provides a baseline for change management and for project status and progress reports. Exhibit 2 reports the second most common problem during the development and delivery process is a failure to do proper scoping. A poorly constructed or incomplete WBS results in scope creep, unclear work assignments, schedule dates slippage, and cost overruns. However, be careful of breaking a project into too many WBS levels since that can be construed as over-planning and bureaucratic. A general guideline for the number of WBS levels is:
- Small projects (few months duration, ~US$100,000): 3-4 WBS levels
- Medium projects (6-9 months duration, ~US$500,000): 4-6 WBS levels
- Large projects (>1 year duration, >$1 million US): 6-9 WBS Levels
Note these are general guidelines and the specific needs of each project must be considered when deciding how many WBS levels are required to completely define the project scope.
Once the scope is defined, a plan is needed for successfully completing the project. Forcing project teams to produce the exact same deliverables for every project is not always optimum and reinforces the too bureaucratic, too much planning, and too many forms complaint about project management. The question should be what amount of planning and what project management processes are needed to make this specific project successful? Of course the danger is a project team using this as an excuse for avoiding work that in reality is necessary. Later in this paper a tool called the Project Controls Index will be introduced, and this tool can help project teams make an informed decision on how much project management is needed.
Project plans need at a minimum some sort of a schedule and resource plan. On a straightforward project simple spreadsheets may be sufficient. A more complex project probably justifies use of scheduling software. If the project requires a funding approval, a cost estimate and budget needs to be prepared. The important point is to base the project schedule and budget on the Work Breakdown Structure.
Communications is the verbal or written exchange of information. We communicate to make requests, reach understanding, make decisions, influence others, and provide feedback. Communications technology is advancing at a rapid pace with many new communication devices emerging that should facilitate the quick exchange of information. But all the new technology is also causing communications overload and on some projects the actual result is less effective communications.
One common theme found on successful projects is excellent communications. This starts by identifying all stakeholders and understanding the power and project interest of the stakeholders. Once this is analyzed, the communication needs for the project can be determined. This includes deciding what information to share, who should get specific information, how to distribute the information, and when to share information. On a large environmental clean-up project with an enormous number of stakeholders one effective method used for communicating progress was a project website available to the public. An innovative feature of the website was a live video feed of the project site from a telephone pole located at the site entrance.
Dealing with Agile Projects
The five basic items that must be done on all projects are relevant for projects using a waterfall project life cycle. However, Agile is based on an iterative project life cycle in which adaptive planning along with evolutionary development and delivery are used. On an Agile project there is still a need for the Project Charter since it provides the success criteria and allows the project team to help safeguard the business case over the life of the project. The requirements and solution (project scope) evolve as the project team works with the product owner, so the team will not have a requirements document or Work Breakdown Structure available for project planning.
A common myth with Agile is that planning is not done. That is a misconception since there are five levels of Agile planning including a portfolio strategy, product roadmap, release plan, iteration plan and even a daily plan (Cohn, 2006, p 28). Finally, good communications is very important on Agile projects. The Agile Manifesto includes statements regarding the importance of individuals and interactions and customer collaboration, which requires good communications (Agile Software Development, 2004, ¶3). Therefore, on Agile projects the five basic items are trimmed to three: a Project Charter, a plan and communications. However, two additional items required for project success should be added for Agile projects, and those are a committed product owner and an experienced Agile person (a Scrum Master) on the project team.
Bridge Components for Success
Having a practical project management (PM) methodology in use is the ‘suspension bridge’ to successful projects. A PM methodology provides consistency across projects, improves the productivity of project teams, leads to a higher project maturity level and helps ensure any regulatory requirements are met. Finally, the PM methodology will lead to improved project results! A suspension bridge and project management only work if all of the key elements are in place. This section of the paper will describe the required bridge components for success.
Maturity Model Levels
Adolescents and young adults learn from their mistakes and become mature adults. The same concept applies to project management organizations. A maturity model is a framework for appraising the project management maturity of the organization. “Research shows that companies with higher levels of maturity deliver portfolios with more efficiency” (Foti, 2002, p. 40). In fact, research by the Software Engineering Institute (SEI) of Carnegie Mellon University (CMU) showed that “companies that measured maturity achieved a 35% increase in productivity, a 19% decrease in time to market and a 39% reduction in post-release defects” (Foti, 2002, p. 40).
Maturity models initially started with the Capability Maturity Model (CMM). “In the 1980's, several US military projects involving software subcontractors ran over-budget and were completed far later than planned, if at all. In an effort to determine why this was occurring, the United States Air Force funded a study at the SEI” (Capability Maturity Model, 2008, ¶3). Today there are many maturity models using a five-level scale, providing a starting point for project management assessment and growth. Exhibit 3 shows a typical five-level Project Management Maturity Model (Fincher, 1997, p. 49). Project organizations which establish and consistently use a practical PM methodology as described in this section of the paper will obtain at least a level 3 maturity. Use of a maturity model allows an organization to quantitatively measure the organization project management maturity.
Foundation – Management Support
Implementing a PM methodology is not possible without executive management support; it's the ‘foundation’ which holds the bridge up over the years. An executive champion should be identified and have accountability for developing and maintaining the PM methodology. The role of the champion includes providing sufficient resources to develop and maintain the PM methodology, and fighting the inevitable battles with some business unit management who do not want to be encumbered by the use of project management.
Bridge Towers – Procedures
Procedures are specific practices and methods followed in a definitive order to bring about a result, and provide a standard and repeatable method for project teams to manage projects. Project procedures are equivalent to the bridge towers, providing the guidelines on how to do projects. Examples of common project procedures include project team organization (roles and responsibilities), requirements definition, project schedules, project reviews, risk management, and change management. Shown below in Exhibit 4 is a sample section of a project procedure for change management.
Bridge Deck – Project Process
The bridge deck is the project process, which is the road you follow to have a successful project. A project process is documented using a flow diagram showing the steps followed including key review points. Exhibit 5 shows a small section of a typical project process for the project initiation phase. In addition to the flow diagram, a process guide is typically prepared. This is a usually a Word document and provides a brief description of each process step including any deliverables and participants.
For most project organizations, more than one project process is needed. All organizations need a waterfall project process, and this process works best when well-defined requirements and scope exists, such as a construction project or commercial software package installation. However, some projects will probably be done more effectively using an Agile approach, such as projects exploring new business processes, or having evolving requirements and scope. Finally, a streamlined project process should be established for small and straightforward projects.
Suspension Cables - Templates
Templates are the specific forms used to record and communicate information created by the project team over the project life cycle. Templates are the suspender cables holding up the project process, and include both project management and technical documents. Use of standard templates increases the productivity of project teams and ensures a repeatable method is used to convey the same type of information on each project. Templates can be created using Word, Excel, Microsoft Project or other software applications or even on-line forms or packaged project management software. Some typical project management templates include Project Charter, stakeholder listing, requirements document, project schedule, Project Plan, project review checklist, risk register, action items, meeting minutes, status report, change request, project acceptance, and close-out checklist.
Having a practical project management (PM) methodology in use is the ‘suspension bridge’ to successful projects. The ‘bridge’ benefits include shorter and more consistent project schedules, improved cost management, higher project quality, functionality completely delivered, and satisfied customers.
However, do not overlook the importance of having competent project managers with the requisite project management and interpersonal skills needed to deliver successful projects. This will probably require training in general project management topics such as scheduling and risk management, along with training in interpersonal skills such as leadership, team building and negotiations. Think of training as part of the investment to get your organization to at least a level 3 maturity.
Project Controls Index
Projects should not be treated the same. A large, complex project of critical importance to the client should receive much more project management attention compared to a small, straightforward project of lesser importance. But how do you decide exactly what project management processes should be applied to each specific project? The client probably doesn't have enough project management knowledge to make an informed decision. The project team may have a bias towards less or more project controls, but any decision they make will be open to scrutiny since the logical question is the basis for their decision. The solution is use of a simple tool called the Project Controls Index (Lukas, 2006, p. 3) shown in Exhibit 6. It provides the guideline for defining the appropriate amount of project management that should be applied to a project to help ensure success. The Project Controls Index is a simple worksheet that when completed will help determine the appropriate level of project procedures, documents and templates to use on a project.
The primary categories for determining the appropriate Project Controls Index to use are cost, security level, and technology risk. The definitions for the four security risk levels are as follows:
- Level 1: High cash or operations impact with significant financial risk
- Level 2: Financial and/or external reporting risk with large financial risk
- Level 3: Data capture and/or operations, or small financial risk
- Level 4: Management and internal reporting risk
The secondary categories are time, installation sites, regulatory requirements, project complexity, business value, and risks. For each category the project team highlights or circles the appropriate choice for the project in the low, medium or high columns. The team then decides on the controls level decision (high, medium, low) for the project based on the selections made, giving more weight to the primary categories. However, if a project has a security level of one (1), a high controls level must be used regardless of the rating for cost, technology or the secondary categories. For all other projects, the team may decide to classify the project differently than from what the cost category indicates if a preponderance of the secondary categories falls under a certain controls level. For example, if a project cost is US$550,000, with technology previously used at the company, level 3 security, with most or all of the secondary categories falling under the definition of a low controls project, then the appropriate approach may be to do the project with low controls.
Once the control level decision (high, medium, low) is made for the project, the project team reviews the Project Phases Checklist, which lists the project management and technical documents that should be used, along with key required activities for each project phase.
Exhibit 7 shows the Initiation Phase checklist for a sample project. TIP-Off is an acronym that stands for Technology, Infrastructure and Project Management Office review. The selections from the Project Phases Checklist should be consistent with the recommendation based on the established controls level. Any deviation from the standard list should be explained in the Exceptions and Comments section of the table.
Some client organizations are pushing back on the discipline imposed by project management. A frequent complaint is that project management is too bureaucratic, requires too much planning with too many forms to complete and results in projects taking longer. These are all valid complaints, as some project managers get too engrossed in blindly following a process and lose sight of the bigger picture, which is meeting the project objectives for the client.
Project managers should focus on the five key items needed on all projects: a Project Charter, defined requirements, a WBS, a plan and communications. Having a Project Charter, defined project requirements and a Work Breakdown Structure provides a solid foundation for the project. All projects need a plan, but the question should be what amount of planning and what project management processes are needed to make this specific project successful? Finally, excellent communications is a common theme found on successful projects.
Organizations also need a project management methodology, since this is the ‘suspension bridge’ to successful projects. Implementing a PM methodology is not possible without executive management support; this is the ‘foundation’ which holds the bridge up over the years. Project procedures are equivalent to the bridge towers, providing the guidelines on how to do projects. The bridge deck is the
project process, which is the road you follow to have a successful project. Templates are the suspender cables holding up the project process, and include both project management and technical documents. The Project Controls Index helps determine how much project management is needed for a project based on key criteria such as cost, duration, complexity, and risk.
Project organizations which establish and consistenly use a practical PM methodology as described in this paper will obtain at least a level 3 maturity. Use of a maturity model allows an organization to quantitatively measure the organization project management maturity and to show improvements achieved over time.
Organizations that follow the suggestions in this paper will simplify their projects, save time and money while still doing the essentials needed to ensure project success.
Agile Software Development. (2004, May 6). In Wikipedia, the free encyclopedia. Retrieved July 20, 2014 from http://en.wikipedia.org/wiki/Agile_Manifesto#The_Agile_Manifesto
Capability Maturity Model. (2005, October 13). In Wikipedia, the free encyclopedia. Retrieved July 20, 2014 from http://en.wikipedia.org/wiki/Capability_Maturity_Model
Cohn, M. (2006). Agile Estimating and Planning. Massachusetts: Prentice Hall.
Fincher, A. (1997, September). Project management maturity model. PMI 28th Annual Seminars & Symposium, Chicago, Illinois, USA.
Forrester. (2013). The state of modern product delivery, challenges and trends making product delivery responsive, iterative, and collaborative in the age of the customer. Boca Grande, FL: Forrester Consulting.
Foti, R. (2002). Maturity. PM Network, 16(9), 40-43.
International Institute of Business Analysis. (2009). A guide to the business analysis body of knowledge (BABOK® guide) – Version 2.0. Toronto, Ontario, Canada: Author.
Lukas, J. and Fulmer, K. (2006, October). On the road to success: Development of a project management process, procedures, documents and training for Sunoco's IT organization. PMI Global Congress, North America 2006, Seattle, Washington, USA.
Mieritz, L. (2013, May 27) Gartner survey shows why projects fail. Retrieved from http://thisiswhatgoodlookslike.com/2012/06/10/gartner-survey-shows-why-projects-fail/
Project Management Institute. (2013b). A guide to the project management body of knowledge (PMBOK® guide)—Fifth Edition. Newtown Square, PA: Author.
Project Management Institute. (2014). PMI's Pulse of the Profession™: The high cost of low performance. Newtown Square, PA: Author.
Project Management Institute. (2013a). PMI's Pulse of the Profession™: Navigating complexity. Newtown Square, PA: Author.
Suspension Bridge. (2002, April 4). In Wikipedia, the free encyclopedia. Retrieved July 20, 2014 from http://en.wikipedia.org/wiki/Suspension_bridge
© 2014, Joseph A. Lukas
Originally published as a part of the 2014 PMI Global Congress Proceedings – Phoenix, Arizona, USA