top of page
Search

Driving better Project Outcomes Through Project Management Knowledge

  • Writer: W Y
    W Y
  • Mar 15, 2024
  • 11 min read

Why Understanding Project Management Concepts is Critical for all Business Professionals not Just Project Managers

 



Big Picture

Project management principles, such as those outlined in resources like PMI's Project Management Body of Knowledge (PMBOK), encompass a substantial and specialized knowledge base essential for anyone involved in project work. Regrettably, a considerable number of professionals lack sufficient expertise or training in project management, placing both themselves and their organizations at a distinct disadvantage. Nonetheless, there are proactive measures that business professionals and organizations can undertake to enhance their understanding of project management concepts and best practices, ultimately optimizing project success and return on investment.


A Critical Lack of Knowledge

“Why is the ‘ROM’ so far off from the final cost for this project?!” If had a dollar for every time I heard this... Herein is the reason for this article: when used by someone trained in project management principles, terms such as a "ROM" have precise meaning. It is not just a cost "estimate." It is a specific type of estimate. One unfamiliar with this term might think a ROM is a definitive, final cost estimate. This can be a damaging mistake and endanger project success. And if you don't know what a ROM is, keep reading!


In this post, I contend that a deficiency in understanding project management concepts can breed confusion, often leading to poorly executed projects that fall short in delivering value or experience scope creep, resulting in cost overruns. I emphasize the crucial role awareness and training play can play in bridging this knowledge gap, empowering both professionals and organizations to enhance project outcomes significantly.  Business leaders immersed in project management principles can enable better outcomes. 


As I was writing this this, PMI published the Pulse of the Profession (available here), which touches on some of the topics I address below, and is definitely worth a read.

 

The Project Management Body of Knowledge

While some organizations still operate informally without embracing established project management principles, many large enterprises have dedicated teams well-versed in these project management methodologies. Various sources suggest that the growing demand for operational transformation will result in a need for nearly 3 million new project managers by 2030.


Those with extensive project management expertise, particularly those who have undergone formal training, communicate using a specialized language. Failure to comprehend this language among all project stakeholders, especially sponsors or product/business owners, may lead to suboptimal projects. This lack of alignment can result in missed project objectives, overlooked critical product features, and ineffective communication and controls.


Most of the core project management concepts have been captured in the Project Management Body of Knowledge (PMBOK), currently on its 7th edition (free for download with Project Management Institute membership). There are other documents that further build on this knowledge, such as the PMI Guide to Business Analysis. Additionally, to recognize one's understanding of these concepts and related best practices, there are also numerous certifications professionals can pursue, such as the CAPM® and the PMP®.


The intent of this article isn't to teach project management, but rather to introduce key concepts and common traps, with the hope of highlighting why it is helpful to get a better understanding of project management concepts to enable more successful projects. There are plenty of books and other resources, some listed below, can provide a deeper understanding of project management to be more effective in your job.

 

Starting a Project

What is a Project.  A project is a temporary endeavor undertaken to create a unique product, service or result. This is important. A project's purpose is to create business value. 


Establishing Business Value. Prior to beginning a project there is usually pre-work. For example, the functional team (and sometimes a project manager or business analyst) will develop a business case. Developing a business case is a good practice and will articulate why the organization needs to pursue a project and what value can be expected (e.g., deploying new software). Value can take multiple forms, such as financial or satisfying a regulatory requirement. The business case is generally used to develop the project charter, which initiates the project.


Process Groups and Processes

Understanding the Main Process Groups is key to navigating project management. These five groups provide a broad framework or outline for project development and delivery, often operating iteratively rather than as one-time activities. Briefly outlined below are the five project management process groups:


  • Initiating: This stage establishes value, reviews feasibility, and develops a project charter to authorize the project's existence.

  • Planning: Following initiation, planning begins, involving the development of a project management plan, scheduling, risk management, and addressing quality, cost, and time considerations. A key concept here is “progressive elaboration,” where the project plan starts out wide and becomes more specific as more detail is uncovered.

  • Executing: This is where the actual work is performed, following the project management plan.

  • Monitoring/Controlling: The project manager tracks overall performance and makes necessary adjustments, managing risks along the way.

  • Closing: This phase formally concludes the project.


Within these five major process groups, there are 49 processes, encompassing tasks such as developing project charters, identifying stakeholders, planning schedule management, and monitoring risks. While not everyone needs to be familiar with all 49 processes or various project management tools unless serving as a project manager, a general understanding of the overall structure proves helpful. Whether you're a product owner, sponsor, or another stakeholder, awareness of these processes allows for meaningful contributions at various project stages. Each project should also be tailored to account for complexity, risk and uncertainty. Some processes may not be useful or needed.


Starting Out and Ensuring Project Clarity - Why We Are Doing This, Defining Success

With an overall outline in mind, it is then critical to understand how projects are authorized and objectives are captured and defined. The last thing you want is to being a project that is not approved by the organization and aligned with strategy, or complete a project and go over budget, miss requirements, or simply not finish!


To avoid a lack of clarity on a project's expected outcome, there are helpful processes and tools captured in publications like the PMBOK. These following are generally developed during the initiating and planning stages:


  • Project charter – An approved project charter authorizes the existence of project and sets forth high-level success criteria, risks, budget, etc.

  • Identifying Stakeholders - As used in project management, a stakeholder can be anyone associated with the project. Identifying these will help with gathering requirements and supporting communications and stakeholder management.

  • Deliverables - Specific, measurable milestones delivered in various project phases that demonstrate progress toward completion.

  • Project management plan - Sets forth how a project will be executed and helps keep the project on track. It is also an iterative document that can be updated during the project.

  • Scope statement - Sometimes included in a project charter, this document sets forth what is included / excluded from the project. It often articulates constraints, risks and assumptions.

The distinction between projects and operations is often blurred, but it shouldn't be. Clear project charters, scope statements, and acceptance criteria are crucial to defining what a project aims to deliver and what success entails. On numerous occasions, I've seen senior leaders questioning “project” issues that were, in fact, operational concerns that seeped into the project. Establishing consensus on a project's purpose, cost, schedule, and final acceptance criteria is required in preventing post-project finger-pointing or overlooking critical capabilities.  Keep in mind there are “transitional” costs and activities that may need to be spelled out, such as data migration – not core to the project but needed to maximize a deployment.


Scope

Project scope is important to understand. Scope is about what the project intends to deliver and should only include work needed to complete the project. Two terms are important from the outset:


  • Product Scope - describes features or functions to be delivered. It informs the project scope.

  • Project Scope - This is the work needed to deliver the project. This is what the project intends to accomplish.


In traditional, waterfall or predictive projects, scope is typically defined clearly from the outset. This works well with projects such as building an office building.

Projects with more uncertainty usually adopt an agile methodology. With agile and hybrid projects, scope may evolve over time. The team will need to determine the work to be done and the number of sprints needed to complete the work. Agile, including sprints, is discussed more fully below.


Requirements Gathering. This is the crucial process of extracting and identifying the essential needs and features required to achieve project objectives, ultimately defining both the product and project scope. The gathered requirements contribute to the scope baseline and play a key role in shaping the Work Breakdown Structure (WBS). Additionally, the process provides valuable insights into the clarification of costs, schedule, and quality aspects. In the context of requirements gathering, the terms 'Acceptance Criteria' and 'User Stories,' in Agile, are often used. These refer to specific conditions or features that must be delivered to the customer, typically assessed on a pass/fail basis.


The scope statement and scope baseline are useful in ensuring the project is on track relative to plan and way for project managers to control scope, preventing scope creep and possible "gold plating".


Schedule

Once the requirements gathering process is complete, the next critical step involves crafting a well-defined project schedule. This entails translating the identified needs and features into a structured timeline, aligning with the project's objectives and scope. The schedule, a pivotal component of project planning, integrates seamlessly with the clarified costs, providing a comprehensive framework for resource allocation and task sequencing.


In this phase, attention to detail is key, ensuring that the project timeline not only meets the objectives but also adheres to the specified quality standards. Effective coordination between project team members is facilitated through a clearly defined schedule, fostering a synchronized and efficient workflow. As part of this process, using a traditional methodology, the Work Breakdown Structure (WBS) developed during requirements gathering serves as a foundational guide, breaking down the project into manageable components for systematic scheduling and execution.  In agile, change is welcomed and that can cause planned releases to evolve, thereby shortening or lengthening the overall project schedule.


Costs


Projected Costs. So, were you stumped earlier with “ROM”? Project cost is an important concept. So, let’s start here.  ROM, or, Rough Order of Magnitude, is truly the roughest estimate of project cost, and can range from -25% under to 75% over final cost. In my experience, 100-150% over cost is not uncommon. A ROM is often done before a deeper, formal requirements gathering process. This is why the ROM is often far from being close the final cost of a project!   Next, is the budget estimate.  It is usually withing -10% to 25% of budget, and in my experience, this is what most non–project management professionals think they are getting with the ROM.  Finally, the definitive estimate is done deeper within the planning stage of the project.


Change Request

Having a well-documented changed management process is critical to ensure scope and costs are controlled. Change management in a project refers to the systematic approach of managing any alterations to the project scope, timeline, or resources in a controlled and organized manner. The process typically begins with identifying a need for change, followed by a thorough analysis of its potential impacts. Typically, there should be a formal approval process for the change as it can impact cost. Once approved, changes are communicated to stakeholders, and appropriate adjustments are made to the project plan, budget, and schedule. Effective change management fosters adaptability and agility, enabling project teams to respond swiftly to evolving circumstances and ensuring project success amidst dynamic environments.


Closing a project

Finally, closing a project should not be an afterthought. This final stage is to ensure that all work has been completed, deliverables are transferred, contracts completed and vendors paid, and resources returned.


Project Methodologies

As you engage in projects, you will hear a lot about project management methodologies. There are dozens. And some are more process improvement approaches than true project management approaches. In short, a project management methodology is set of principles that project managers use to plan, execute and manage a project.


Different Types of Projects Methodologies. There are many but generally two are mentioned most frequently: predictive (waterfall) and agile (iterative). Many organizations use hybrid approaches that employ both.  


The main difference is that with predictive a majority of the planning for the entire project at the outset, usually where there is a lot of certainty around the work to be done. Agile is more iterative and the project manager and incorporates feedback along the way. For a variety of reasons, agile is popular and understanding the specific language of agile is a good next step. Often with agile, there are interim releases that are iterated upon as work moves forward.


Key Agile Terms (selected): As agile is so widely popular, it is important to have some familiarity with agile terminology. If you are working on an agile or agile-hybrid project, you are likely to hear some of these terms:


  • Product (Business) Owner - person designated to represent the customer and provide requirements

  • Product Backlog - The customer's project requirements.

  • Sprint Backlog - work selected to be completed in the next sprint.

  • Sprint - A 1-4 week iteration where team work to complete work in the sprint backlog

  • Daily Stand-Up Meeting - brief, daily meeting, led by the agile project manager or scrum master to discuss team's work

  • Sprint Review - inspection done with customer, product owner at the end of a sprint

  • Retrospective - review of lessons learned at the end of a sprint

  • Release - several sprints worth of work set for roll out to customer


Minimum Viable Product (MVP). From a project management perspective, it is often a goal to achieve an MVP as soon as possible. Often an MVP is one phase of many in a project. For an IT-related deployment, an MVP might include getting software up and running with minimal feature to start getting immediate return of value on the project work, as well as a tool that can be iterated upon as project phases move forward.


People / Teams Associated with a Project

Project Manager. The project manager is ultimately responsible for the overall management of the project, scheduling, ensuring appropriate communication with stakeholders, etc. However, how project manager works across different organizations can be often fairly complex, depending on alignment. Is the role dedicated? Matrixed? Full-time or temporary? The role may also combine responsibilities of a dedicated analyst (explained below). Knowing how a project manager's role is aligned within an organization is helpful for maximizing influence, communication strategies, obtaining resources, decision-making, etc.


Business Analyst. Where there is a dedicated role, the business analyst supports the project on items such as requirements documentation, data analysis, process analysis, etc. However, in smaller organizations or lower complexity projects, the project manager might do these tasks as well.


Supporting (or Directing Functions)

In addition to the project manager, analyst and business owner, there are other important functions that may be involved in a project:

  • Project Management Office (PMO) - PMOs have different roles at different organization, some closely oversee projects and budgets others provide more of a support function. It is helpful to know how your PMO operates as your project team may need to interact with them regularly.

  • IT Function - for many projects, IT is heavily involved in all aspect of projects and they will likely have resources that interact with the business unit / product owner to develop requirements and build out the product backlog

  • Procurement / Vendor Managment - When vendors are involved, this group is often involved in reviewing vendors against retention criteria. The procurement team often negotiates the contract. The vendor management team is usually responsible for ensuring day-to-day performance.

  • Quality Assurance - most organizations have QA functions. Like the PMO, their roles can vary, but they may have an interest in your project or may need awareness.

  • Legal - there can be a variety regulatory requirements associated with a project

  • Privacy office

In some organizations the above functions have significant overlap.

 

Additional Tips/Takeaways:

  • Establish Clear Value / ROI. If you're a sponsor/product (business) owner or a project manager make sure your project satisfies a clear business need (provides value) with an appropriate level of ROI that the business agrees upon in advance. This must be in writing and will be captured in a few locations, including the project document.

  • Be Engaged in All Aspects of the Project. As a product owner you need to provide requirements and feedback to the team.

  • Change Management. For many projects, there are numerous stakeholders and end-users that may be impacted by a project. It is important to consider the needs such as training and cut-over issues and timing.

  • Communicaiton. Exceptional communication with stakeholders is essential, and probably warrants a separate approach. However, suffice it to say you want to ensure awareness, buy-in and support of your project.


Call to action:

The above are just some major project management terms you may hear, and not a definitive list. The point of this article mainly to highlight potential knowledge opportunities or gaps and to suggest the following next steps:


  • Upskill. If you are frequently involved with projects, you need to grasp the core language and principles of the project management professional. It will make you easier to work with, more effective and lead to better overall project outcomes.

  • Organizational Training. Many professionals won't take the step to get upskilled. Thus, it is imperative that organizations provide basic training for sponsors and business owners to improve PM outcomes.


Resources

 




 


 
 
 

Comments

bottom of page