Viewing Posts by Kevin Korterud
by Kevin Korterud
It used to be that projects that were typically small in size, localized to a single team, and compartmentalized to the point where they didn’t collide when it came to schedules and resources. Over time, projects began to be packaged into programs that involved larger teams as well as a greatly expanded technology footprint. To manage these complexities of modern-day project delivery, organizations are increasingly turning to enterprise program management offices (EPMOs) or enterprise delivery management offices (EDMOs) that span waterfall and agile initiatives.
The need—and demand—for enterprise PMOs and DMOs is only growing with the pandemic. Here’s why:
The business process landscape has become more imbued with technology— to the point where there’s no such thing as a business or technology project anymore … just delivery. And while the meteoric growth of tech has fueled success, it also creates challenges. It’s now common to have multiple delivery initiatives underway across a technically integrated landscape that can include everything from centralized enterprise resource planning systems down to personal mobility apps. In addition, project/program delivery and agile product delivery are taking place at multiple speeds and frequencies. Design, deliverables and testing all become much more demanding. All of this leads to the strong probability for delay on one initiative to cause schedule and resource conflicts.
EPMOs and EDMOs can provide technology enablement and assurance functions needed to keep delivery on track. For example, enterprise-enabled testing and scheduling tools whereby delivery teams can form, execute and implement requirements and user stories—without having to spend effort to acquire tools and train team members—saves precious time.
Early in my career, a senior project manager told me the best way to reduce costs on projects is to finish them on time. That advice remains relevant. As companies rely on technology as well as project, programs and transformations to create a competitive market edge, any sort of schedule delay reduces value. Delaying a market launch of a new mobile product entails parking resources, additional communication efforts, etc. Plus, given today’s landscape, a delay in one initiative can cause a chain reaction that affects other dependent initiatives, thus exacerbating the overall negative impact to business value.
Through integrated schedule, resource and dependency planning across delivery initiatives, EPMOs and EDMOs trigger early warning mechanisms and help marshal senior leadership decision-making to help mitigate delays.
Today’s delivery landscape is dramatically different from the past. Along with the size, scale and varying modes of project, program, transformation and product delivery, multiple third-party labor and hardware/software suppliers are more deeply involved. It’s also more common for delivery initiatives to have a global footprint, adding another layer of complexity. And COVID-19 further exacerbates these challenges by inhibiting communication, collaboration and impacting hardware/software supply chains.
Let’s use the analogy of a busy airport, where there’s a need for a centralized function to help harmonize the way different people, processes and technology components work together. In that case, distinct sector, tower and ground controllers organize the flow of traffic, minimize delays and in some cases avert potential disastrous conflicts.
The same rationale holds true for EPMOs and EDMOs, which are uniquely positioned to provide essential services such as: common delivery methods, third-party supplier and supply chain management, enterprise-level risk management, integrated scheduling management, resource management and dependency management.
I sometimes long for the simplicity of small, compartmentalized projects that could move at their own pace to completion. However, we all have to face today’s delivery reality. Some ways of working we were all used to may come back with the pandemic under control, but in the meantime we still have delivery responsibilities—and EPMOs and EDMOs can be a big help in making sure we meet those responsibilities.
To what degree are you seeing the need for enterprise EPMOs and EDMOs?
Demanding Stakeholders Are Good Stakeholders
By Kevin Korterud
Managing the dynamics of stakeholder engagement is an essential component of successful delivery. Stakeholders offer direction and support, and enable key strategic and tactical decisions needed for delivery progress.
Especially early in our careers, we tend to think about stakeholders as being two-dimensional entities that have an equal say in delivery directions. For those of us who have completed several project, program or product delivery initiatives, we know this equally representative model of stakeholders does not practically exist.
At one time or another, we’ve all had a demanding stakeholder. True demanding stakeholders tend to be standouts from the traditional body of stakeholders in several dimensions.
Demanding stakeholders are almost always well-intended. They seek a path to delivery results and are not focused on gaining political capital for their own personal benefit. However, their dominating professional presence, business/technology domain knowledge and sense of urgency can be intimidating.
Project, program and product managers early in their careers often make mistakes in working with demanding stakeholders. Many of us tend to misinterpret their high level of needs as a liability. In fact, the opposite is usually true with demanding stakeholders. With a proper connection, they tend to be one of the most valuable assets for effective project, program and product delivery.
Below are three techniques for re-thinking the way you interact with demanding stakeholders:
1. Recognize their unique strengths and skills.
There is no mistaking what a demanding stakeholder needs from a project, program or product delivery initiative for success. In addition, their needs are made very clear as to what success looks like from the delivery team.
Demanding stakeholders typically possess strong business and/or technical knowledge, which gives them a highly capable foundation from which to quickly enact the best possible slate of improvements. They understand these processes end-to-end and typically have an external view of how other companies execute the processes.
Demanding stakeholders are also often efficient communicators who can phrase their needs in the minimum amount of words. In addition, they can readily visualize and demonstrate to others the required elements and outcomes from prospective improvements.
Leveraging these skills, demanding stakeholders can readily align their improvement ideas with organizational strategy. This alignment is key to realizing the maximum amount of value from a project, program or product solution.
By doing so, the demanding stakeholder—by having the best interest at heart for real results—is a key factor in true delivery success.
2. Practice setting boundaries, and use “not now/yet” vs. “no.”
The size and scale of a demanding stakeholder’s needs may at first seem daunting. In addition, there often doesn’t seem to be enough time to meet their needs. The demanding stakeholder realizes that there is typically a limited opportunity to enact high-value change, so they try to maximize what can be done—even if it means running over schedule and budget.
When interacting with demanding stakeholders, start by setting the boundaries for the size, scale and duration of improvements that are possible. Mutually agree that these boundaries are solid and can only be revised with a change control process. By setting these boundaries, you can enable the next step in optimizing demanding stakeholder needs.
Saying “no” is not an effective path for progress. The approach should be to set a grouping, ranking or other priority-based construct that can be used to determine the relative order of stakeholder needs. By using more of a “not now/yet” approach, you create clarity into the relative importance of needs, while building the bridge for future enhancements.
3. Become a demanding stakeholder yourself.
One of the most effective approaches for working with demanding stakeholders is to become one yourself. For a project, program or product manager, this is quite straightforward due to the disciplines already inherent in the work that we do on a daily basis.
To increase business or technical knowledge, put yourself in the role of a demanding stakeholder. Seek opportunities for business or technology immersion through training, shadowing the stakeholder’s subordinates and visits to company sites or customers to fully appreciate their position.
With any stakeholder engagement, such as a working or status meeting, devote additional time and effort to preparations. Role play and predict the likely set of questions or directions that would be provided by the demanding stakeholder. Leverage your team members to assist with demanding stakeholder dialog.
Demonstrate the ability to make fact-based and data-driven decisions in a quick and decisive manner. In addition, clearly communicate acceptance criteria, timing and desired outcomes to team members. Pay strict, unwavering attention to the scope, scale and time boundaries. Finally, fully support the demanding stakeholder with any change control effort needed to revise scope, scale and duration boundaries.
By exhibiting the core behaviors of a demanding stakeholder, you will gain the respect of that stakeholder and let them know they have a willing and capable partner in creating value for the company.
What are some ways you’ve successfully collaborated with demanding stakeholders?
By Kevin Korterud
When I first started as a technology project manager, it was not uncommon for a project to have just one deliverable. All of the tasks in the project created the path that led to the single deliverable, which in many cases was a program, report or screen. Life used to be so easy!
As projects became more complex, the need grew for multiple project deliverables that lead to a complete solution. Deliverables now represent the “building blocks” that form a key foundational element of any project.
Whereas scheduling tasks is a fairly straightforward process that involves capturing durations, resources and successor/predecessor networks, scheduling deliverables comes with its own set of complexities. Deliverables don’t always behave in a linear manner like tasks—so special considerations come into play with their scheduling. In addition, there are typically people and expectation factors that need to be part of a deliverable scheduling model.
Here are three essential reminders for properly scheduling deliverables:
Whereas tasks are singular items that stand alone in a work plan, deliverables have a few extra packaging steps in their path to completion.
One of the most dangerous scheduling mistakes to make with deliverables is to have a single task in a work plan that represents the deliverable. This is because of the variation in duration and effort that it takes to complete a deliverable.
Deliverables have a natural path to completion that involves a package of tasks, whose dynamics differ from normal tasks in a work plan. Project managers need to include these extra tasks that chart the lifecycle of a deliverable from initiation to completion.
For example, a sample set of deliverable task packaging would appear as follows:
You can tell from the above table that prior to scheduling deliverable task packages, project managers need to have a deliverable governance process in place. A deliverable governance process that identifies specific deliverable reviewers and a single approver are key to the effective scheduling of deliverables.
2. Deliverables May Require Task-like Linkages
We are all familiar with creating predecessor or successor linkages between tasks to form a linear series of work needed to achieve an outcome. Those linkages serve to drive schedule changes as prevailing project conditions occur.
Deliverables can require the same sort of linkages found in tasks. For example, if you have deliverables that lead to the creation of a marketing web page that involves multiple supplier deliverables, selected tasks in the deliverable package can contain task linkages. These linkages impose conditions which determine the pace at which related deliverables can be completed.
Let’s say there are three design documents from different suppliers required to create an overall design document. The build of the overall design document cannot finish before those three supplier design documents are all approved. So in the work plan, delays and schedule movements in the supplier design deliverables will drive the true completion date of the overall design document.
In addition to the scenario of having deliverables with dependencies, it is just as likely to have a set of deliverables that do not have any dependencies at all. These deliverables need to be completed by the end of the project but do not directly figure into the final outcome of the project. These are often process improvement deliverables that are needed for future projects that are not ready for execution.
When a project manager has a slate of unrelated deliverables, the optimal approach is to bundle them into agile-like sprints. The content of each deliverable sprint is determined by a balance of resource availability for the people who build, review and approve deliverables, as well as any form of relative priority. For example, if deliverable reviewers have low availability during a scheduled deliverable sprint, those deliverables can be pushed to a subsequent deliverable sprint.
Priority can also determine the content of deliverable sprints. Higher priority deliverables would displace lower priority deliverables to future sprints, even if work has begun on those deliverables. For example, if there is a strong need for a certain tool to be used by multiple projects, those deliverables would move into the current deliverable sprint. The deliverable sprint process allows for agility, while balancing value created from the deliverables.
As I shared earlier, life was so much easier when projects created one deliverable. Different times demand different approaches to managing deliverable schedules—especially on large transformations where there could be hundreds of dependent and independent deliverables. The last thing anyone wants to do is insufficiently manage deliverables: Leaving out one of those “building blocks” might cause the house to fall over.
What tips do you have for deliverable scheduling in today’s project ecosystem? Share your thoughts in the comments below.
By Kevin Korterud
The definition of a successful PMO has changed over time. Today, a highly complex delivery ecosystem is the norm in most organizations. So PMOs that serve primarily as a “back office” function, providing only operational support services, are not seen as adding value. They are viewed as a means of reducing costs by assisting project, program and product managers with operational tasks.
The same can be said for the PMO lead in today’s modern organization. Organizations are turning to their PMO leads to share insights, impart predictability and strive towards the preservation of business value. Today, leads need capabilities that to a great degree mirror their project, program and product delivery leadership counterparts. A highly visible leader with a broad perspective across both delivery and business operations is rapidly becoming a key role in a delivery organization.
Based on the changing PMO landscape, here are what I see as the three essential characteristics of contemporary PMO leads:
The inherent complexity of projects and programs continues to increase as more of the business landscape is automated. In addition, there is growing opportunity for technology and process innovation. Projects and programs can morph into persistent and recurring product development, which in turn creates an environment where delivery is continuous.
PMOs over time have also matured in lockstep with delivery complexity and persistency. PMO service groups have mechanized and industrialized PMO processes to support this growth. In concert, the charter of a PMO has shifted from being just a pure service function; it is now expected to serve as a predictor as well as an enabler of delivery.
These factors put a PMO generalist at a distinct disadvantage. With higher expectations, it’s key that PMO leads have project, program and product delivery experience. These delivery skills provide insights and observations that are more organic in nature and go beyond what is found in status reports; their delivery experience allows them to get to the “so what” insights as well as to realistically predict delivery trajectory. In addition, prior delivery experience makes them more credible as a PMO lead with their project, program and product delivery peers. This also gives them the capability to become an adjunct delivery lead where required.
2. Ability to Conduct Delivery Assurance Reviews
Organizations today can have hundreds of concurrent projects, programs and product delivery initiatives. In addition, the use of delivery performance metrics and other indicators can vary widely. While metrics have always been a useful starting point to determine the overall health of delivery, they don’t always reveal potential volatility in a timely manner.
Delivery assurance reviews go beyond the metrics to explore the factors behind the current trajectory of project, program and product delivery. These reviews are objective examinations conducted on behalf of an organization’s senior leadership to uncover potential delivery “surprises” not visible in status report metrics. The accumulation of delivery surprises over the entire portfolio can readily add up to a significant loss of value.
Leveraging their prior experience, today’s PMO leads are adept at conducting delivery assurance reviews. Enabled with a PMO charter that has been approved by senior leadership to mitigate delivery surprises, the combination of prior delivery knowledge as well as a value-driven mindset allows them to successfully execute delivery assurance reviews. Their organic ability to answer the questions “Where are we, where are we going and will we get there in time?” positions the PMO lead of today as a key team member within a delivery organization.
Today’s delivery ecosystem is a highly complex, fast-moving environment that demands a high level of people engagement. As a project, program or product delivery leader, the ability to seamlessly connect with organizational leadership, stakeholders and suppliers has proven a key factor in delivery success. The same can be said about today’s PMO leads.
In the past, PMO leads and their respective teams were viewed more as an accessory to core delivery activities. Their services were employed directly to a project, program or product delivery lead; they rarely interacted with senior leadership, stakeholders or suppliers. However, today’s delivery ecosystem can tax the capacity and capability of delivery leadership. They need a peer partner who will help them achieve delivery success. To do so requires that the PMO lead understand both delivery and business operating models.
This new PMO interaction model requires that a PMO lead possess a persona that can credibly engage with senior leadership, stakeholders and suppliers. They need to understand both delivery and business operations; the latter coming about from either professional study or exposure through prior delivery experience. While a PMO lead cannot understand every facet of business operations at a deep level of detail, having this exposure makes for more efficient and effective engagement with stakeholders as well as suppliers who are also key contributors to delivery success.
The PMO Lead of Tomorrow
Not long ago a colleague told me they were going to take on a PMO role in an organization. When asked about their motivation to do so, they shared that there were no current project, program or product delivery lead roles open, so they thought this would be a good place to start in this organization.
Much to my delight, this person had a strong background in delivery, professional training in relevant areas of business operations as well as plentiful experience engaging with leadership, stakeholders and suppliers. I smiled to myself that although they had no prior PMO experience, they had all of the right skills to succeed as a PMO lead.
PMO leads need all three of these skills in order to succeed in today’s modern delivery ecosystem. For the PMO lead of tomorrow, they’ll require even more skills to deal with ever-increasing demands for project, program and product delivery. This will position them to play an even greater role in the delivery success of an organization.
I’d love to hear from you: What do you think makes for a good PMO lead?
By Kevin Korterud
It’s quite possible that, if asked to remember every project I led over the years, I would be hard-pressed to do so. Our typical project management journey takes us down a new road when we complete a project, so we’re never really stopping to take a retrospective on how each one shaped who we are today.
A much easier exercise for me is to recollect which projects played a significant part in shaping my journey as a project manager. These projects, not unlike silver polish, brighten our skills and capabilities to a shine that allows us to undertake even larger and more complex projects.
Here are three projects that had a profound impact on my capabilities, and what I learned from each:
Up till a certain time in my project management career, I felt that my work included some rather large projects in terms of team members and scope. However, nothing prepared me for the massive construct that is a transformation program involving almost 2,000 people.
Transformation programs extend well beyond the realm of what project managers normally lead. They involve significant changes to business processes and technology, as well as altering what people do on a day-to-day basis. In addition, there are many project and team members involved with multiple, parallel tracks of work. All of this makes a project manager feel as small as the tiny people in Gulliver’s Travels.
Transformation programs pushed me to think and engage externally beyond my assigned project, especially when it came to dependencies between projects. I also realized it was essential that project managers collaborate and cooperate in order to maintain progress for the overall transformation program.
2. Technology Is in Everything
Over the years, I have followed with great interest the increase in the proportion of a project that involves technology. On my first projects many years ago, the level of technology was quite modest, relying mostly on data inputs, online screens and reports that augmented existing business processes. Today, technology permeates nearly all facets of a project.
When asked to assist with the estimation and implementation of a new type of airliner, my initial assumption was that there would be some form of enabling technology and the airliner would still operate as before. For example, there would be some technology support required, but the fundamental functions would not really change.
After reviews and discussions, I was astounded at the depth of technology that was found in this new model. The flight deck had provisions for laptops to be used by pilots to both prepare and operate the airliner. Flight operations and integration tasks that were once managed manually were now conducted automatically and at high speed, all of which reduced pilot and ground crew workloads. The technology found in this new airliner caused me to dramatically re-think the level of rigor required to estimate and plan its implementation. In addition, it raised my expectations of the effort required to estimate and plan today’s projects in order to ensure quality delivery.
As we consistently execute project delivery over and over across a number of projects, our growing confidence can sometimes cause us to view project delivery as commonplace. We can begin to lose our sensitivity towards project outcomes as we proceed through a seemingly endless stream of phases, sprints, tasks, activities and artifacts of project management.
A big wake-up call for me occurred when I led a project to process calls from customers of infant nutritional products. Customers would call in on a variety of topics ranging from inquiries about the right product to use as well as potential infant health issues. Before I formally began the project, the sponsor reviewed with me existing customer cases showing both simple inquiries as well as potential emergency health issues. I realized then that my efforts on this project could potentially save the life of an infant.
It’s easy to think about projects as two-dimensional entities that refine business processes and technical capability. From the dialogue with the project sponsor, I came to appreciate how this project could improve both the time and quality of response on an inquiry related to the health of an infant. This motivated me and the team to always be thinking about how this project would interact with the customers in the most effective and efficient manner, especially when the life of an infant could be at stake.
As we all proceed through our project management careers, we tend to remember the distinct impact these projects had on us. Some of the projects affect how we plan projects, others influence project execution and still others will be remembered for how they served as key waypoints in our project management journey. In addition, these “waypoint” projects are well-suited as experiences to share with the next generation of project managers following in our footsteps.
What projects on your project management journey have shaped who you are today?