Viewing Posts by Kevin Korterud
By Kevin Korterud
Beware: Strategic initiatives aren’t the same as typical projects—they tend to be considerably more complex. For example, strategic initiatives are usually bound by some form of dramatic urgency around schedule (regulatory, market), costs (process improvement) or consumer satisfaction (subscription, satisfaction).
But the differences don’t end there. Let’s look at some other complex dimensions that must be considered when leading a strategic initiative:
1. Stakeholder Management
The stakeholder landscape is much more broad on a strategic initiative than a project. In strategic initiatives, stakeholders typically span multiple departments within a company, creating multiple primary stakeholder groups. And these stakeholder groups will often have nearly equal shares in the success of the initiative, thus creating potential authority conflicts.
In addition, there are also governance functions—risk management, legal, etc.—that will have either a primary or secondary stakeholder role.
The complex stakeholder landscape necessitates communication processes that serve vastly different audiences. There exists both a two-dimensional communications problem: one dimension is horizontal (i.e., across stakeholders) and the other is vertical (i.e., involving higher levels of leadership). What once was a linear communication process on a project now becomes more of a matrix process to deal with the breadth and depth of stakeholders.
Communications will need to be carefully tailored to different functions and levels of stakeholders. For example, more detail for operational functions, and simple, high-level summaries for leadership consumption.
3. Progress Tracking
Strategic initiatives bring with them inherent complexities that can quickly overpower the progress report tracking processes that are commonly used to manage projects.
For example, strategic initiatives will typically have more suppliers than on a typical project. These additional suppliers bring with them different commercial arrangements, delivery methods, status reporting formats and progress metrics. On top of that, all of these progress tracking components need to be harmonized across the various suppliers in order to achieve a cohesive and durable view of progress position.
Project managers will need to review, refine and agree on common progress tracking processes, reporting and metrics that are universally accepted by all suppliers. By creating this single harmonized view of progress tracking, you are more readily able to identify and address delivery volatility.
When first presented with the prospect of leading a strategic initiative, project managers need to balance the excitement of leading a high-visibility engagement with the practical realities of effectively and efficiently managing delivery. By putting essentials in place, project managers can successfully move on to the next step in the career journey: leading their second strategic initiative!
What essentials can your share with project managers new to strategic initiatives that will put them on the path to success?
By Kevin Korterud
As project delivery methods have evolved, so has project leadership. Hybrid approaches have emerged: Traditional waterfall project and program managers are now faced with the prospect of having a portion of their work use iterative agile approaches. Agile Scrum Masters and product managers executing rapid iterations of new products now have to contend with budgets, financial forecasts, release schedules and business case benefits, as well as with aligning implementation of products with other projects across the enterprise.
With this as a backdrop, a frequent question that comes up from my colleagues is whether an industry needs a project manager who knows agile, or agile leads who are competent in more traditional project management practices. In today’s complex world of delivery, we urgently need both.
1. Project Managers Need to Understand Agile
It’s inevitable that a project manager will at some point oversee an agile delivery process. So it’s important that project managers start their journey to competency as soon as possible. This journey can begin with training in agile methods as well as shadowing an agile lead to see how the iterative process works.
As the journey continues, project managers will start to immerse themselves in advanced areas such as agile metrics, alignment of agile to testing and release processes as well as the people factors. A project manager will soon see what sort of projects can best be delivered through agile vs. waterfall methods, as well as the linkages to enterprise functions required regardless of delivery approach.
2. Agile Leads Need to Understand Project Management
Agile leads typically have experience with iterative methods used to quickly shape and deliver solutions. In addition, they typically have a strong business analysis background that comes into play when defining user stories.
In the past, these skills alone were sufficient for agile delivery efforts.
With the complexities of contemporary delivery, however, many agile leads now encounter similar expectations when it to comes to schedule, budget, product quality and business case realization as their waterfall counterparts.
These expectations compel agile leads to gain skills in traditional project management areas such as estimation, forecasting, resource management, technical requirements as well as testing and implementation practices. Acquiring these skills will enable agile leads to deliver higher-quality products in a more timely and efficient manner.
3. Everyone Needs Enterprise Function Support
As hybrid project delivery approaches become more common, the considerations for aligning delivery activities to produce the most value to an organization become more numerous. These considerations can include (but are not limited to) the speed at which agile produces product iterations, business and technology complexities, and the increasing expectations of consumers.
All of this amplifies the importance of enterprise functions such as portfolio management, release management and resource management. These and other traditional enterprise delivery disciplines have been identified by the Scaled Agile Framework (“SAFe”) as being key to success.
It’s not so much that the SAFe framework has had a “eureka moment” around enterprise functions as new innovations. Rather, it has identified the critical need to have these functions in place and engaged for all types of delivery. Both project managers as well as agile leads can be more successful when tightly integrated with enterprise functions. Without having robust enterprise functions in place, organizations will struggle with more frequent schedule, resource, dependency, testing and implementation conflicts. And those conflicts dilute the business value of projects regardless of delivery style.
What do you think? Do organizations need agile leads with project management knowledge, or project managers with agile knowledge? I welcome thoughts regarding delivery successes and failures relative to either or both roles.
By Kevin Korterud
My last posthttp://www.projectmanagement.com/blog/Voices-on-Project-Management/20344/ offered two tips for project managers who want to develop a big-project mindset while executing small projects: leverage support resources and implement quality assurance practices. But why stop there? Here are two more.
1. Understand Change Management
It’s easy to think small projects don’t require many business change management activities. But even a project that has a modest projected budget could face unforeseen change management activities.
For example, I worked on a project several years back that was straightforward to implement but required specialized support for remote locations. The original project budget estimate had not considered this.
Even for projects of modest size, project managers should examine the need for business change management activities such as business process transitions, different types and levels of training materials, and measuring the timely adoption of the functionality the project creates.
2. Validate the Project’s Complexity and Forecasting
Project managers running small projects are often handed a budget and schedule that allow for neither timely nor successful implementation. This usually comes about from poor estimation processes that don’t take into consideration the necessary complexity analysis typically found on big projects.
This in turn can create budget and schedule errors of a much larger percentage than the small project can absorb. In addition, small project schedules can be affected by adjustments of large projects if they share a project or technical dependency, which creates unanticipated impacts to schedule and budget.
Project managers can save themselves a lot of future pain by initially confirming the complexity assumptions for the project before proceeding. In addition, project managers running small projects still need to undertake the same level of forecasting rigor found on large projects: resource availability, work planning, milestone progress, cross-project and technical dependencies, business outage windows and other considerations that can more greatly impact a small project.
When project managers “think big” on small projects, it allows them to be successful no matter the size of the project. Do you have any advice for project managers running small projects on how to think big?
By Kevin Korterud
It’s typical for new project managers to be assigned to a small project to build their skills. Why? Small projects have a limited value at risk, a modest budget, a shorter schedule and a smaller team. But project managers early in their career who have successfully led small projects often ask me how they can move on to leading big projects.
Small projects, to some degree, can be more difficult to lead than larger ones. You are given much less in the way of reserve budget, schedule and resources. However, big projects are not just smaller projects with larger budgets and longer schedules. They have inherent complexities relative to stakeholders, scheduling, resources and deliverables not found on small projects.
My recommendation to project managers wanting to move to larger projects is to “think big” while running smaller projects. Thinking big involves adopting, where possible, practices required for large projects.
Here are two ways project managers can think big on projects. My next post will offer two more tips.
1. Leverage Support Resources
Many times, project managers running small projects attempt to perform all of the project operations activities themselves. This can include creating new work plans, calculating progress metrics, scheduling status meetings, and performing a host of supporting activities for the project.
While it may be a source of great pride to a project manager to perform these activities, they represent an opportunity cost. In other words, the project manager could instead be working on higher-value activities like stakeholder management or risk management.
Employing support resources even on small projects can save valuable time and costs. It also means the project manager doesn’t have to spend time becoming an expert in the tools and internal project operations processes. By having other people assist with the mechanics of building project plans and producing metrics, the project manager will have additional capacity for running the project.
2. Implement Quality Assurance Processes
Project managers on small projects tend to become immersed in a level of detail not possible on large projects. The small project also allows for deep interaction with team members that may not be effective on large projects.
In addition, a project manager on a small project may be tempted to start serving in roles akin to a business analyst or technology designer. This can distract the project manager from actually running the project.
To keep focused on project management activities, quality assurance processes should be implemented. Phase gate reviews, deliverable peer reviews, change control processes, quality performance metrics and the definition of project acceptance criteria are all good examples of quality processes. With the implementation of these processes, project managers can focus on deliverables and outcomes without getting too deeply immersed in the details of the project.
Check back for my next post on more ways project managers can develop a big-project mindset while executing small projects.
By Kevin Korterud
I’m frequently asked how program managers can synchronize projects using waterfall approaches with those using agile or other approaches. As programs are launched to address larger and more complex business problems, harmonizing a program’s projects becomes an essential component of success.
In my last post, I shared two tips for achieving harmony: remember that there’s no such thing as agile or waterfall programs, and make the correct delivery approach choice before a project begins.
Here are two more tips.
3. Establish a Program PMO and an Agile COE
One of the critical success factors for any large program is the program management office (PMO). The program-level PMO enables the program manager to spend time on higher-value activities while the PMO creates the operational governance, reporting and overall management foundations required to run a program.
As agile and other delivery approaches mature, there is a great need for a COE (Center of Excellence) model that fosters efficient and effective delivery approaches for projects on programs. Just as PMI has created a consistent approach to project management, agile and other delivery approaches are at a point in their maturity cycle where consistency is needed for them as well.
An agile COE can facilitate this consistency while serving as a clearinghouse for improved agile practices. This COE can also address different variants in waterfall, supplier and governmental delivery approaches, thus resulting in an overall harmonized approach for program and project delivery.
4. Speak the Same Metrics Reporting Language
George Bernard Shaw once said, “England and America are two countries separated by a common language.” Being a program manager with projects utilizing multiple delivery approaches can feel like living in one country separated by multiple languages!
On a program, it is essential that no matter their delivery approach, projects need to be able to both accurately describe their progress and do it in a way consistent with other projects. When dealing with projects with multiple delivery approaches, a suitable translation needs to be in place for progress metrics. This is particularly necessary for stakeholders such as finance, human resources or other business functions where an easily understood definition of progress is critical.
For example, agile projects do a great job in counting projected versus actual requirements and their weighted points. Using the total and completed requirements, a percentage completion can be calculated that is consistent with a waterfall delivery approach. Other agile-specific metrics such as effort per story point can be used to supplement the core progress metrics.
In addition, even between waterfall delivery approaches there needs to be defined a consistent approach for earned value structures, tracking actual cost and other progress essentials. (Note that aside from progress metrics, the concepts of risks, issues, dependencies, milestones, cost forecasts and governance escalations all remain the same no matter the project delivery approach.)
Program managers are orchestrators of both project delivery and the attainment of business results. They need to be always thinking about eventual business outcomes, no matter which delivery approaches are in play. Remember: no one chooses an airline or car model because the company used agile or waterfall on their projects—it’s all about the experience.
What methods have you seen employed in programs to handle multiple delivery approaches?