Preparing Your Project Expedition – Part 1 Setting the Foundation

It is common knowledge that most projects fail to meet initial performance criteria (i.e. schedule, cost, quality, and/or functionality) for any number of reasons. The Internet contains countless articles dedicated to “the reasons for project failure” topic. The theme seems to be rooted in poor planning from project inception, often due to limited understanding of expectations. Frequently, companies request managers, or staff, to prepare and direct a project, yet these resources are not equipped or experienced enough to do so; typically they are unsure of the resources to engage or the questions to ask. The purpose of this article is to help those of you in this position to establish a grounded and well-informed start for your project.

Project Management Process

Think of a project as a journey. Typically you know where you begin, so what is your final destination? Without knowing your destination, how can you map out your journey? Let us assume a project has begun and your company has assigned it to you to manage and execute. At this point you are at project inception, as depicted in Figure 1. A high‐level goal to get some product or service delivered has been requested, but no project organization has been defined, no staffing resources have been defined and no roadmap has been provided. Before you start detailed planning, you should ensure expectations are well defined; these expectations begin to define the scope of the project.

 Figure 1: PMBOK ‐ Project Management Processes

Additionally, it is always recommended that the first action be engaging a Project Manager (PM). The PM is the steward of the project, a key decision maker, an organizer, a director of activities, and a mediator. The PM needs to be engaged from the beginning, taking part in developing the direction and relationships for the project. It is the PM’s job to ensure business goals (i.e. success criteria) are defined and achieved. If you have been given this role, congratulations! Otherwise, you should secure an independent contract with an experienced PM, even if your company is just doing preparation work for the development phase of the project (e.g. feasibility research, Request for Proposal development, etc.). The PM should lead the development and submission of the first document for the project: the Project Charter. The project scope is initially defined in the Project Charter. The Charter is where the project’s foundation is laid and the project executives/sponsors agree to the initial, high‐level expectations; the rule of thumb here is the more details established and documented, the easier it is to set and maintain the direction of the project. Too many unknowns are certain to increase the risk for scope creep, a delayed implementation, cost overages, and ultimately customer dissatisfaction.

Project Management Trinity

The information gathered at the beginning of your journey will determine whether the project can weather a storm or crash at the first signs of rain. Not to say that the project will crash should an oversight occur; however, rectifying an oversight has a cost and too many oversights will increase cost and risk and affect your journey. Any oversight will impact what I call the project management trinity (a.k.a. Triple Constraint): time, cost (resources), and scope (see Figure 2). Through thorough planning, it is your goal to establish a solid baseline for each of these factors and minimize any deviation.

Figure 2: Project Management Trinity (Triple Constraint) Diagram

It is certain that when one factor of the trinity changes, the other two factors are impacted as well. The impact can be positive or negative depending on the change. For example, should a project be granted additional time to complete its objective, the quality may be improved, whereas the cost will most often increase due to additional unplanned man hours. In another example, should the scope of the project decrease, then, in essence, the cost and the schedule should decrease as well because the project no longer needs the man‐hours or time to complete its objective. Understand that these are theoretical assumptions based on the premise that cost, time and scope are relative, but the reality is that many forces contribute to a positive or negative impact on the factors. As in the later example, the schedule may stay fixed because the scope change eliminated features that were not on the critical path, yet the overall project cost would be lowered if the project were a feature-based, fixed‐bid contract.

Project Categories

To help your critical thinking, we are going to break things into four basic categories: Project Management, Business, Technical, and External Partners (see Figure 3). Our goal is to focus on each category and identify what the company expects as outcomes for the various parts of each category. In completing this exercise, you increasingly clarify your destination. Again, with a clear understanding of your destination, you are better equipped to define “how” you are going to get to your destination, which is the planning process of the project.

Figure 3: Project Categories Diagram

When you think about the Project Management category you must not only think about the project at hand, but future projects as well, especially if one of the expectations is to establish ongoing project management and control practices. Your goal is to identify those expectations related to schedule, project reporting (metrics), project communications, project control, oversight, contracts, and logistics. The Business category represents the primary customer. When we talk about the Business, we want to ask questions pertinent to that Business; topics such as funding, product/service features, key business policy & regulations, functional Subject Matter Experts (SME), user support and user training, data and data security, business processes, and business partner relationships. Sometimes in a project, the Technical is also the Business when the project is a “technology only” undertaking, such as a hardware or software upgrade. The Technical category is obviously the technology side of the project. Technology supports the business. Your goal is to understand the technological expectations for the project. You want to gather information related to key technical policies, specifications, processes, security controls, and infrastructure, as well as operations and maintenance staffing that is required during and after the project. When you think about External Partners, external should be interpreted as entities outside of the core business group. An External Partner may be an outside entity or another business group within the same company, using an entirely different system, but sharing some level of data or functionality; they may be a contributor, a consumer, or both. Your goal is to identify those expectations that fulfill the business commitment to these partners, such as electronic data exchange, user access/training, and communication. In subsequent parts to this article, we are going to delve into specific questions to consider for each of the four Project Categories. We intend to explain why these topics may be important and what the potential impact may be if these are not considered during the early stages of your project journey.

Lessons Learned

Before we conclude this discussion, I want to address one more topic that every project management practice professes: “Lessons Learned.” As a part of your preparations, you should research the “Lessons Learned” documentation from other projects, especially ones at your own company or from projects with similar scope and objectives. “Lessons Learned” can provide useful insight and perspectives that may lead to further improving your preparation and planning efforts to shorten or improve the roadmap for your project. Conversely, include in your own project practice an ongoing mechanism for capturing your own “Lessons Learned.” What you learn may help the next leader make key decisions for defining a better roadmap on their project. Remember, Project Management is a practice, you learn with every experience. If you don’t experience it, you will never learn. Stay tuned for Part 2 – Project Management Considerations.

Resources & References:

A Guide to the Project Management Body of Knowledge (PMBOK Guide) ‐ Fifth Edition. Project Management Institute (PMI), 2013. Paperback.  Fourth Edition. Project Management Institute (PMI), 2008.

“Four Common Reasons Why Projects Fail.” West, Cynthia Ph.D . Project Insight , n.d. http://www.projectinsight.net/white‐papers/four‐common‐reasons‐why‐projects‐fail

Project Management Survey Report 2013. KPMG, July 2013. Report. http://www.kpmg.com/NZ/en/IssuesAndInsights/ArticlesPublications/Documents/KPMG‐Project‐Management‐Survey‐2013.pdf

“Project Management Triangle.” Tutorialspoint. 2014. http://www.tutorialspoint.com/management_concepts/project_management_triangle.htm

“Why Do Big IT Projects Fail So Often?” Jim Ditmore. InformationWeek, October 2013. http://www.informationweek.com/strategic-cio/executive-insights-and-innovation/why-do-big-it-projects-fail-so-often/d/d-id/1112087

“Why Projects Fail – 101 Common Causes.” Ryder, Greg. Calleam Consulting Ltd. WordPress, n.d. http://calleam.com/WTPF/?page_id=2338

“Why Projects Fail – Facts and Figures.” Ryder, Greg. Calleam Consulting Ltd. WordPress, n.d. http://calleam.com/WTPF/?page_id=1445

*Lessons Learned contributions provided by Michelle LeFeve, Sharon Christman, Sharon Pizzuti and Steve Trudell of Courtland Consulting.

Author: Anthony Sessions, Senior Consultant Courtland Consulting