"If I want to receive the benefits of Integrated PM, then I need some kind of Performance Measure Framework, but this requires an upfront investment in requirements definition."
I’m told the definition of Project management is the ability to administer a series of chronological tasks resulting in a desired goal, but Lynchpin theory is not far from this definition, nor is Integrated PM. But definitions can be misleading, the magic is in the application.
Leadership new to Integrated PM, may find themselves envisioning a map, like the one above, when attempting to get their arms around Integrated PM. As you begin disciplines like Knowledge Management, Behavior Change Management, Asset Management, Process Improvement Management, Portfolio Management, Product Management, Program Management, Risk Management, Change Management, and so on…, all are integrated with the project management that you once thought you understood pretty well.
The trick is a robust requirements management practice which defines the scope. This helps contain the relevant disciplines within any one Integrated PM system. All this leverages a system architecture which is used by all projects, and once developed, provides a single source of truth that provides an access point for maintenance and growth. At pmNERDS, we refer to this architecture as the Performance Measure Framework, and will address this in more detail in other posts and courses.
Depending on the business needs and goal of the client sponsor, project client, and project manager some Integrated PM facets or disciplines may play a more important role in the specific project then others. The policies, procedures, guidelines, constraints, practices, and organizational enablers are all predefined for each Integrated PM discipline within the Performance Measure Framework. Each of these facets let the project manager look at the project through the lens of the various disciplines, searching for any applicable requirements for the current project.
Of course, if there are any specialized requirements, now is the time to bring specialists in to help gather project requirements. The business need of why a project has been created really drives the implementation of a project as it should, and not tradition and/or politics. Business needs can be to increase efficiency, to increase productivity, to respond to a customer request or a new regulation, or for countless other reasons a project is initiated. The project manager must understand what's driving the project and how the project supports the business need, the mission of the organization, and how the deliverable of the project will be used by the stakeholders.
I’ve listed some common sources of project requirements other than those established as procedural requirements found in the performance measure framework here:
- Project clients and final users
- Project sponsor
- Portfolio review board
- Program managers
- Project Management Office
- Project team
- Functional management from Sales, Marketing, Development, Engineering, and so on.
- Operations management including finance, manufacturing, training, logistics, and Human Resources
- Business partners
- Project manager
These requirements typically come from interviews, polling, and other market sensing practices. How will you know what the end result of the project is to be? Ask! Who do you ask? People like the project sponsor can answer these kinds of questions. More about that later! You must have a clear vision of the end result, or the project will drone on and on forever and you'll never finish. Too often projects can roll into project after project stemming from an original, indecisive, half-baked wish list. Imagine your favorite archeologist maneuvering through a labyrinth of pitfalls, poison darts, and teetering bridges to retrieve a golden statue. In the movies, there's always some fool who charges past the hero straight for the booty and gets promptly beheaded. Don't be that guy. Before you can rush off toward the goal of any given project, you've got to create a clear, concise path to get there.
To create this path, you'll have to interview the decision makers, the users the change will affect, and any principals involved in the development of the technology. These are the stakeholders- the people who will use the project deliverables on a daily basis or will manage the people who will use the project deliverables. You must have a clear vision of what the project takes to create it or you're doomed.
As you begin your project, consider the following questions:
- Does the Project Have an Exact Result?
- Are There Industry or Government Sanctions to Consider?
- Does the project have a reasonable deadline?
- Is the project sponsor someone who has the authority to christen the project?
- Does the project have a financial commitment?
- Is someone else doing this already?
- How will this new product affect your users?
- Will this product affect other projects or existing products?
- Who else is using existing solutions?