Key functional partnerships (KFPs)
achieving strategic, operational, and tactical alignment
While addressing many challenged programs and projects, especially those in engineering, technical, and formal design-basis industries, a clear pattern of dysfunctionality emerged. The pattern showed a clear disconnect between functional roles and responsibilities that lead to misunderstanding, misalignment, and misfires in scope development and execution. Upon further observation, it became clear that the disconnects occurred within specific key functional partnerships (KFPs) along the organization's hierarchy (strategic to tactical).
This paper details results from misalignment, insights, and distinctions for recognizing and implementing key functional partnerships; their constructs, objectives, roles, responsibilities, strategies, and practices.
Challenges and Observations
Anyone who has spent time assisting challenged programs and projects has been exposed to organizational, personal, and functional hurdles. A successful project management consultant usually takes these challenges with a grain of salt, steadies the project, makes sure the “recovery team” has a grasp on the revised solution, and then moves on to the next set of locations, faces, and challenges.
A successful consultant who is involved with assessing, adjusting, and re-implementing solutions begins to recognize patterns connected with negative results. Although they may be found in different industries and cultures, these negative results have similar, if not identical, characteristics.
In assisting teams with recovering challenged projects, this level of insight helps us focus on the areas of the project that will turn it around. On long projects, it is easy to lose track of these patterns yet, the patterns that lead us to coin the phrase key functional partnerships (KFPs) caused so many deep-rooted organizational, programs, and project problems that we began to formalize our observations.
The Patterns That Emerged
The patterns that emerged in programs and projects exhibited these characteristics:
- All in the fourth quartile of their respective organization's cost and complexity classifications. Most of them were extremely challenging to “first of kind.”
- All in the challenged category, with some approaching contractual default.
- Multi-year in duration and predominantly not estimated well, having been budgeted instead.
- Large teams (many international) comprised of many functional contributors.
- Required a major technical, engineering, and/or formal design basis requirement for scope development and execution.
- Required key design leads or technical leads as key core team members.
- Complex and critical implementation risks; many with no practical mitigation or contingency possibilities (late recognizing them).
- All program and project organizations had many years developing their products and in many cases were “sole-source” providers for key customers.
- Lastly, all organizations were matrix in structure and had (or espoused) some form of formal project management life cycle or methodology (level of commitment was the issue).
Many patterns were observed that were consistently emerging from the program and project characteristics mentioned previously. Though there are many more beyond the ones listed here, the following list provides a starting point.
- Critical contract and scope negotiations performed by senior executives without consulting the program or project manager, which resulted in major scope inclusion without balancing cost, schedule, and technical considerations.
- Complexity bias: Organizations believing the program or project was “just another one” and in many cases included “first of kind” technology and/or complex implementation requirements.
- Program and project managers’ experience and opinion minimized by overreaching senior executives.
- Where program and project methodologies were present, key best practices succumbed to time constraints; “We will catch it later”…and they didn't!
- Also in many organizations, the key distinctions between program and project were blurred at best.
- Disconnects between program/project managers and key functional resource managers resulting in difficult relationships.
- Key integration points in the program/projects (and the critical thinking required) were minimized and sometimes missed. For example, in an organization implementing an internal drafting workflow system that would impact design deliverables and key regulatory submissions, no one recognized that a training program had not been developed for the new system, and the program was 12 months late at the time.
- A general yet alarming sense of functional malaise. In some cases, resources were taken from key “bet your company” programs to work on smaller “pet projects.”
- Missed, inaccurate, and non-integrated roles and responsibilities and a critical lack of “partnership” to achieve complex expectations on very strategic programs/projects.
An Approach for Resolution
I would like to say that we recognized and addressed these patterns quickly; unfortunately, that was not the case. We did recognize that from program to program and project to project, the resources were in their daily functional roles yet, disconnects arose within their functional roles in the program and project context.
In addition to this “program/project disconnect,” many of the organization's resources were unaware of the importance of vertical alignment (strategic to tactical) as pictured in Exhibit 1.
Exhibit 1: Strategic, Operational, and Tactical Alignment
This became evident in Pattern #2 (Complexity Bias) as we observed key resources in denial declaring that major and customer critical program/project efforts were “cookie cutter” in nature and they had “done these before,” when clearly they had not. While key executives understood the criticality of succeeding on these challenges, that realization did not make it deep enough into the organization.
During our “project recovery assignments,” we interviewed resources from the strategic to the tactical level. We discovered that the resources had a common frustration. They assessed themselves as working hard and collaboratively at their daily functional roles and could not understand why the programs and projects were failing. As a result, they thought the program or project manager was the issue.
When they were asked about their level of proficiency and collaboration in the functional roles of the program/project, the majority did not see any distinction between their daily functional roles and their functional roles within the program/project environment. This was not a surprise yet, it did begin to explain the misalignment and malaise we were observing. Many of these organizations also had roles and responsibilities documentation within their PrgM-PM methodologies yet, it was apparent that this alone was not sufficient.
During a one-on-one meeting, a program manager for a very large and critical manufacturing project (a key component for next generation nuclear plants), was asked, “In connection with the program, if you could have something (information, relationship, resources, etc.) that you don't currently have that would make a key difference in the program, what would it be?”
Interestingly enough he said, “If I had a closer relationship with the senior vice-president/plant manager and was in the know about program information at his level, I could share that (appropriately) with my project managers. I don't need to know everything he knows, just the program information he has. At times I feel cut off from a level of information and collaboration that would help me, the project managers, and the lead engineers make better decisions.”
When this information was relayed to the senior VP/plant manager, he was a bit taken back as he thought he was acting in alignment with the roles and responsibilities documentation in the methodology…and he was.
These findings were presented to other program managers from different organizations. They agreed wholeheartedly and together we arrived at the following conclusion: In these types of large, complex, and critical programs/projects, where a design or execution flaw could derail a very aggressive schedule, that alignment from the top to the bottom wasn't enough. What was required were deeper relationships, partnerships in fact, where key program/project functionality was the basis.
A Basic Model
Initially, we created a simple map (Exhibit 2) of what key functional partnerships were required for the type of programs/projects we were engaged in.
Exhibit 2: Initial Mapping of the KFPs
These “partnerships” have distinct “functions” (roles, objectives, practices, and expectations), which result in effective context, alignment, transparency, communication, and execution.
Virtually none of this was earth shattering. We were re-defining (or refining) the level of detail for effective roles and responsibilities required for these complex program and project efforts. As we further developed the map/model shown in Exhibit 3, we realized that each role in the four KFPs had specific functions to perform that fell into two categories. In the program/project context, we were most concerned with the second category.
- Key functions, although required, fell outside of the KFP (day-to-day functional responsibility by virtue of their position in the organization).
- Key functions within the KFP that both roles must share together to ensure project success. These functions must be transparent, fit to the program/project, and aligned with other KFPs.
These “functions” are also associated with specific “levels” within the organization; strategic, operational, and tactical. Exhibit 3 represents further definition of the KFPs and the key functions (functional responsibilities) within each level of the current program.
Exhibit 3: Further Definition of Key Functionality at Each Level
Exhibit 4 is a progress map of the model representing both vertical and horizontal (organizational) alignment.
Exhibit 4: Progress Map of the KFP Model
The key functionality has been added and mapped for each KFP (horizontal) and program level (vertical). Originally, we were tempted to include the finite practices and processes in the middle column yet, opted for generic key functionality. At the point of implementation, these key functions must be translated into specific practices and processes that are captured in the program/project execution plans.
Based on the size and shape of the program or project, there may be additional key resources and therefore additional KFPs. The model is not static and like all other sound program and project management tools, requires proper “scaling” to be practically and successfully implemented.
Once we worked our way through the basic model, we began implementation on a major program that was in serious condition, approaching default on a key customer contract, and therefore open to a new approach. Exhibits 5 through 8 represent that initial detailing of the four program specific KFPs by the program resources. Required strategies – practices and misalignment insights information were added.
Exhibit 5: Initial Detailing of KFP1
Exhibit 6: Initial Detailing of KFP2
Exhibit 7: Initial Detailing of KFP3
Exhibit 8: Initial Detailing of KFP4
Overall, the implementation was successful; the program was readjusted to a new baseline yet, implementing a new approach in the middle of a distressed program has its challenges. The following implementation considerations are generic and can assist in formulating a plan for introduction, implementation, and acceptance.
- Change Management: Implementing any new process or practice in a program, project, or organization is a form of “culture shifting.” Best to include the scope of any required change management initiatives in the initial program/project setup (charter). This will be easier to implement when it is part of the program/project.
- Sponsorship: Even though it may be included as part of the program/project, implementation will still require an executive sponsor to influence organizational resources and opinions that are adverse to change.
- Mapping: When creating the program/project specific map, keep the KFPs simple and focused on the core program resources and key functions required. Obviously, there will be many more resources on the program yet, traditional roles and responsibilities documentation can be used for non-core team resources.
- Facilitation: Facilitating the mapping and customizing (scaling) process is an effective role for the project management office (PMO) and should be part of initial program set-up for large, complex, and organization critical efforts.
Although key functional partnerships (KFPs) are basically a redefinition of effective program/project roles and responsibilities, they are valuable at resolving negative patterns that contribute to the distress of large and complex programs and projects.
Implementation of KFPs are best included in the program/project charter as required change management initiatives, and resourced, planned, and executed properly.
KFPs are an effective tool for ensuring vertical and horizontal alignment where the margin for error in technical scope development is very slim and missed timelines will result in execution misses, distressed programs/projects, and the erosion of customer confidence.
© 2013, Thomas Flynn
Originally Published as part of 2013 PMI Global Congress Proceedings – New Orleans, Louisiana
Federal Project and Program Management Community of Practice (FedPM CoP) – How Sharing Best Practices Can Lead to Success
Recognizing the value of a community focused on project practice capability and how such a community could help improve the performance of departments across the U.S. federal government, the leaders…