Author: Robert Wysocki

OUTSIDE THE BOX Forum: When is Agile Required?

Written by Robert Wysocki on January 8, 2018. Posted in Articles. 4 Comments on OUTSIDE THE BOX Forum: When is Agile Required?

We’ve all read articles that talk about choosing between traditional approaches and agile approaches.

Traditional projects can use an agile approach but agile projects cannot use a traditional approach.

There are some projects where that choice is a valid concern. But there are projects where some type of agile approach is not an option. It is a requirement. These are projects where the goal and/or the solution are not clearly defined or understood. In such cases the discovery of the missing piece(s) must be imbedded in the work of the project and that can only be achieved through some form of iterative process. Each iteration is an attempt to learn or discover missing parts of the goal and/or solution. After some number of iterations the goal and solution will be clearly known. To avoid an agile approach some traditionalists might try to jury rig their favorite waterfall model but that thinking is seriously flawed.

So complexity and uncertainty are the factors that lead to the conclusion that some type of agile approach is needed. But agile is a journey not a destination. There are several different agile approaches. So how do we choose the one that is the best fit given the project characteristics? Let’s try to answer that question.

THE COMPLEX PROJECT LANDSCAPE

The most intuitive illustration of the situation is the four-quadrant landscape defined by the two project characteristics: goal and solution. Every project has a goal and a solution to achieve that goal. Complex projects lack some clarity of goal, solution, or both and are found in Quadrants 2, 3 or 4. All of them will require some type of agile model.

Figure 1: The Complex Project Landscape

Agile Models Ranked from Mostly Defined to Mostly Undefined

After 25 years of client engagements where all types of agile projects were planned and executed I have adopted a ranking from mostly defined to mostly undefined. You might also use least complex/most certain to most complex/least certain. This is not an objective ranking. There are at least a dozen models that could be included. I’ve only chosen five for this article to illustrate the point. Each is briefly discussed. For a more complete treatment see [Wysocki, 2013]. The ranking is quite subjective but based on my personal experiences in using the models. There are also variants of each of these that affect their application.

Prototyping

This is a tried and true approach couched in the language of the client. There are a variety of variations from iconic models to production models. Prototyping is a very robust tool with a long history of uses including even the most complex and uncertain of project situations. Those would be situations where the project manager is using prototypes to suggest a starting point for the client to get on board with the search for a solution. Prototyping is a tool that keeps the client in their comfort zone during that search. It is quick and simple. There are several software applications that can generate and modify prototypes in real time.

Advertisement
[widget id=”custom_html-68″]

Evolutionary Development Waterfall

The only reason for using this is that it keeps the development team in their comfort zone. Project teams that have a long history of using the Waterfall Model will often choose this as their first step towards an agile environment. Unfortunately that is probably the only reason for using it when the situation calls for an agile model. It is very inefficient and wasteful of resources and time.

Scrum

The agile project world is dominated by Scrum [Schwaber and Beedle, 2001]. It is a sound model that keeps the client in charge through the Product Owner. That is, if you have a properly skilled Product Owner. Of all the common development models Scrum is a customer-driven model. Scrum does not have a project manager but the role is subsumed primarily by the team of senior developers, which operates as a self-managed and self-directed team. Co-location of the team is a critical component. Scrum teams tend to be small (less than 10 members). The temptation is to equate Agile to Scrum. There are many agile models of which Scrum is the most popular but the complex project landscape is broad and deep and can validly support a much richer portfolio than just Scrum.

Dynamic Systems Development Method (DSDM)

This model is popular in the EU [Stapleton, 2003]. At any point during implementation it allows the team to return to any previous stage in the design, development and deployment of the solution. DSDM is what the Waterfall Model would look like in a zero gravity world.

Effective Complex Project Management (ECPM) Framework

This is the new kid on the block [Wysocki, 2014] and [Wysocki, 2016]. It isn’t a model in the sense of the above. Rather it is a framework (Figure 2) that embraces a portfolio of models and a decision process for choosing and adapting the best fit model from the portfolio.

Figure 2: The ECPM Framework

It can be used for any agile project but is most useful when so little is known about the goal and/or solution that choosing and adapting the best fit model is not much more than a coin toss. it offers a decision model to help in that choice. The major advantage of using the ECPM Framework is that is designed to include the meaningful involvement of the client. ECPM is also a significant step towards establishing a collaborative project environment. Scrum includes that involvement through the Product Owner. The other models do not have meaningful client involvement as a design feature.

PUTTING IT ALL TOGETHER

All of these models and others should be included in the organization’s portfolio and the best fit one chosen based on the project’s characteristics, the organizational environment and culture in which the project will be executed and the market conditions the prevail. The specific types of projects the organization encounters might suggest that other models be included as well as customized models the organization has developed for repeatable projects. Choosing the best fit model is a multi-criteria decision. Preferences and availabilities have a lot to do with the choice. For example, Scrum requires more senior level developers because the projects are self-managed and self-directed. In the absence of senior level developers Scrum would not be a good choice.

[Schwaber and Beedle, 2001] Schwaber, Ken and Mike Beedle, 2001. Agile Software Development with Scrum, Pearson.
[Stapleton, 2003] Stapleton, Jennifer, ed., 2003. DSDM: Business Focused Development, 2nd Edition, Pearson Education
[Wysocki, 2013] Wysocki, Robert K., 2013. Effective Project Management: Traditional, Agile, Extreme. 7th Edition, John Wiley & Sons.
[Wysocki, 2014] Wysocki, Robert K., 2014. Effective Complex Project Management: An Adaptive Agile Framework for Delivering Business Value, J. Ross Publishing
[Wysocki, 2016] Wysocki, Robert K. and Colin Bentley, 2016. Global Complex Project Management: An Integrated Adaptive Agile and PRINCE2 LEAN Framework for Achieving Success, J. Ross Publishing

OUTSIDE THE BOX Forum: Status Reports Must Be Intuitive

Written by Robert Wysocki on December 13, 2017. Posted in Articles. 9 Comments on OUTSIDE THE BOX Forum: Status Reports Must Be Intuitive

You don’t come as an attachment to a Project Status Report and you may have little or no control over…

who interprets them so at the risk of being misunderstood your objective should be to only distribute reports that are intuitive – that are self-explanatory. This is especially important when reporting outside the project team to the sponsor, executive management and the organization in general. Those folks have their own language and understanding of the business which is probably different from yours. Reports to the team need not be intuitive because they are a controlled audience and can be taught how to interpret them. Legends are OK as they support the intuitive nature of the report.

Examples of a Report That Is Not Intuitive

Figure 10.1 is a Milestone Slip Chart. What is it telling you? Without someone to interpret this chart, I don’t know how anyone could explain it. I could guess that the triangles show schedule delays in achieving planned milestones but what does the color coding depict? A legend would have been very helpful. If you are color blind, as I am, this Milestone Slip Chart is useless.

Figure 10.1: Milestone Slip Chart

Examples of Reports That Are Intuitive

Figure 10.2 is an acceptable statement of the general health of a project as measured by plan achievement. The general health of the project can be deduced and some analysis done just based on the display. The legend is helpful although labeling each trend line is also acceptable. This is an historical report much like a burn down chart. The trend line shows that the project got behind schedule in the middle weeks of the project but has since showed signs of recovery.

Advertisement
[widget id=”custom_html-68″]

Figure 10.2: Milestone Completion Chart (MCC).

Figure 10.3 is a Milestone Trend Chart (MTC). It tracks the difference between the planned date for achieving the milestone and its forecasted date. This milestone is planned to occur in the 9th month of the project and is currently running 6 weeks late. The four data points trending in the same direction signals an out of control situation that should be further investigated. This is clearly an intuitive trend chart but it is much more than that. It is an early warning system too. The milestone is forecasted to be 6 weeks late and it is 10 weeks away from its scheduled completion date. Is it too late to complete the project by its planned completion date? Probably. The continued growth in slippage also suggests a systemic cause rather than a single incident that caused the slippage.

Figure 10.3 Milestone Trend Chart

It is obvious that this milestone event is behind schedule and getting further behind at each report month. Quality control measures suggest that a run in the same direction for four successive report dates signals a situation that needs investigation. I first introduced these in the 1980s and have continued to use and develop them further in my consulting practice.

Earned Value Analysis (EVA) is a common tool for assessing project status against planned status. Figure 10.4 is a primitive version of an EVA and is clearly intuitive.

Figure 10.4 Earned Value Analysis

This is a very primitive EVA. More sophisticated versions can track both deliverables variances and schedule variances.

In Summary

Remember to keep your audience in mind as you choose how to convey project status. The less control you have over who reads your reports the more important it is that these reports be intuitive. If the reports are formatted so that only a select few can understand them, then your messages will be ignored by those who are not among the select few.

OUTSIDE THE BOX Forum: Mastering the 10 Challenges to Agile Portfolio Management

Written by Robert Wysocki on November 14, 2017. Posted in Articles. 4 Comments on OUTSIDE THE BOX Forum: Mastering the 10 Challenges to Agile Portfolio Management

Agile projects are those whose goal and or solution are not clearly defined. These projects dominate the project landscape.

Usually some agile or extreme model is used to manage them. They are high risk, high change and their outcomes are not at all certain. Managing portfolios of these projects is very complex and will challenge even the most experienced among us. In priority order the major challenges are:

Organizational support
Project governance
Measuring performance
Meaningfully involving clients
Structuring the project team
Estimating business value
Eliciting requirements
Scheduling constrained resources
Improving process design
Improving product design

This article describes each challenge and offers strategies for dealing with each one.

ORGANIZATIONAL SUPPORT

Organizational support extends from the very highest management levels in the organization all the way down to the project sponsor and the management team to whom the project manager reports. A Project Support Office (PSO) should be in place to offer not only the vetted processes and practices that are needed in an agile environment but also the training and consulting support that a complex project manager and team might require in the discharge of their responsibilities.

PROJECT GOVERNANCE

Complex projects are high risk projects. To mitigate some of that risk decisions should be made as close as possible to the expertise for making those decisions. That responsibility should be assigned to the team. But not just any team. The only decisions that should be made above the team level would be those decisions to adjust priorities, postpone the project or terminate the project.

MEASURING PERFORMANCE

The one common thread that links all projects is the business value that each expects to bring to the client and the organization. Business value would have been the deliverable that was used to approve the complex project and its plan. That might seem like the problem has been solved. Don’t be too quick to judge however. There is much yet to be done. Project performance is the variable that we will use to compare each project, program and portfolio in the enterprise portfolio. That comparison will be used to decide project status for the coming iteration. So we have to include not only past performance but also the prospect for future performance.

MEANINGFULLY INVOLVING CLIENTS

In the traditional project world clients were involved at the requirements elicitation phase and after that only for status reporting and deliverables approval. In the complex project world that is no longer effective. In its place the client must be meaningfully involved even to the extent that they will have management and decision making authority as members of the project team. They are the product experts and will have responsibility for managing the deliverables. The process expert on the team is the traditional project manager. They and the product manager have co-equal management responsibilities for the project.

Advertisement
[widget id=”custom_html-68″]

STRUCTURING THE PROJECT TEAM

To be most effective a complex project team should count among its members those who possess all of the skills and competencies needed to succeed. That includes the decision making needs of the project. The project team template is shown in Figure 1.

Figure 1 ECPM Project Team Template

For a detailed discussion on the Co-Manager Model see Strengthening Client Involvement in the PRINCE2 Process Using the ECPM Co-Manager Model, (PM Times Oct 24, 2015 and PM Times October 28, 2015).

ESTIMATING BUSINESS VALUE

Every project is approved based on the business value it is expected to deliver. In the complex project world the solution is usually not completely known at the outset and must be discovered through iteration. That makes the expected business value that will be delivered very difficult to estimate. As iterations proceed the estimated business value may be different than the expected business value of an acceptable solution. The estimated business value that a project will deliver is often the primary factor underlying approval of the project business case. In a complex project that is seldom more than a best guess. As the project work commences and the solution begins to take shape that estimate is revised. It can change and so can the priority of the project.

ELICITING REQUIREMENTS

In the complex project world it may not be possible to elicit complete and clearly defined requirements. This step is designed into the ECPM Framework. The design is a two-step process that totally eliminates the current problem of incomplete requirements. The first step is a high-level identification of the set of necessary and sufficient requirements for achieving the expected business value delivered by an acceptable solution. How these requirements will be met is left to the second step. The second step is relegated to the iterations and stages of the framework. For details see A Fresh Look at Requirements and Requirements Elicitation in Complex Projects (PM Times, July 28, 2014)

SCHEDULING RESOURCES

If all active complex projects are identified within a portfolio the problems associated with resource scheduling are somewhat reduced. Unfortunately that situation rarely exists. Instead a number of projects that are defined and staffed within a single business unit are not part of any portfolio. While that may be true of a project it isn’t necessarily true of the resources that staff these “below the radar” projects.

IMPROVING PROCESS DESIGN

Complex projects don’t seem to follow any predictable process. Each project presents the team with a unique set of circumstances and challenges them to respond accordingly. That is why the ECPM Framework includes a continuous process and product improvement program. Figure 2 is the continuous process improvement program that has been integrated into the ECPM Framework.

Figure 2: The ECPM Framework continuous process improvement process

In time the organization will build a comprehensive collection of responses.

IMPROVING PRODUCT DESIGN

Figure 1 has also been integrated into the ECPM Framework but adapted to product improvement rather than process improvement. The Probative and Integrative Swim Lane process is the heart of that product improvement effort. It is unique to the ECPM Framework and will not be found in any other project management process.

IN SUMMARY

The ECPM Framework was designed with these challenges in mind. Most of the challenges are mitigated through ECPM Framework design features (Project governance, Measuring performance, Meaningfully involving clients, Structuring the project team, Eliciting requirements,

Scheduling constrained resources, Improving process design, Improving product design). Others are mitigated through the execution of the complex project.

How all of this happens requires a book length discussion and is out of scope for this article.

OUTSIDE THE BOX Forum: Project Managers are Morphing into Change Managers

Written by Robert Wysocki on July 24, 2017. Posted in Articles. 4 Comments on OUTSIDE THE BOX Forum: Project Managers are Morphing into Change Managers

As complex projects become more the norm than the exception scope changes become more frequent.

In fact, these projects expect change requests and cannot succeed without it. It is just part of the learning and discovery process and an essential ingredient of successful complex projects. Maybe project managers have always been change managers but we didn’t recognize them as such. Or perhaps this morphing may be more the result of our taking a more sophisticated approach to managing complex projects. The recognition of complex projects as the real project ushers in an approach tailored to the nuances presented by projects whose goal and or solutions cannot be completely known at the outset but can only be discovered through iteration.

So as a newly recognized change manager, what should the project manager have as tools and how should they be used.

The Role of the Project Manager as a Change Manager

The Change Manager’s objective is to take the organization from where it is to where it wants to be. Sounds simple, but is it? One of the biggest obstacles is to establish and sustain meaningful client involvement. Their representatives on the project team is the best thing the project manager must an expert. But that expertise will be lost if there isn’t meaningful participation. The tools described below are critical to establishing that meaningful involvement.

“To act as an agent of change, managers must have good communication and interpersonal skills so that they can explain the benefits and implications of change”, says Ian Linton of Chron. Strong communication and interpersonal skills of the project manager build a stronger relationship with the client that creates stronger meaningful participation.

William Sheats agrees, “Effective communication throughout the lifecycle of the change initiative is required to enable and achieve a successful organizational change. Communication is the foundation for transferring the knowledge and creating the understanding associated with the specifics of the change.”

There are two tools that may be new to the Project Manager acting as a Change Manager.

1. Bundled Change Management Process

Every complex project should expect frequent change requests. These are the fuel of a successful project. Without these changes, the project is likely to fail. They are the result of the learning and discovery that drive each iteration. With that in mind the project manager and the team must do everything they can to facilitate change requests. That is the good news. The bad news is that someone on the project team must receive these changes, analyze them, decide if and how to implement them and finally adjust the schedule to accommodate them. The human resource requirements can be substantial. These are resources that are no longer available to do project work.

The traditional one at a time process is very inefficient. With that in mind the project manager and the project team must do everything they can to make the change request process simple and efficient.

Jane Suchan PMP from Microsoft agrees with simplicity in the change process, “One challenge for project managers is balancing the need to control project change while avoiding undue bureaucracy. The question is: Where is the tipping point? Because every project is unique, the point at which change control stops adding value and turns into red tape will vary from project to project.”

Simplicity in change management process points to a bundled change management process. Bundling means that the analysis and decisions are made at specific times during the project. That points to the time between iterations when review of the just completed iteration and planning for the next iteration is done.

Advertisement
[widget id=”custom_html-68″]

The process we have designed is called the Bundled Change Management Process (Figure 1). It is a process that works particularly well in complex project situations where change is frequent.

Figure 1: Bundled Change Management Process

The lifeblood of a successful complex project is change. The purpose of each iteration is to learn and discover the specifics of the goal and/or solution. Without change an incomplete solution will never evolve to an acceptable complete solution. The first principle to learn is that every change is a significant change.

What that means is that the change process must be open, simple, lean and as painless as possible to the client for that is where the bulk of the changes will originate.

Note that when the Change Request is received that it is review and if accepted without change is added to the Scope Bank. Only when the stage is complete will the change request be analyzed and further action taken. If the change is approved it could be available for work as early as the next stage.

Change requests can arise at any time and can come from any one of several sources. Furthermore, the request can be well thought out or just a statement like: What would it be like if we could …? Both extremes must be accommodated by the request form that formally enters the idea into the project. The request process begins with a statement from the individual making the request. It is designed to allow the requestor to provide as much detail as is available. The last thing would be to have a requirement that creates an obstacle to suggesting a change. Rather, you would rather have a request form that encourages ideas.

2. Management Reserve

For high change projects, a contingency time budget is a good idea. It works just like a contingency budget of money. If you need it, you spend it.

“Contingency reserve need not refer exclusively to monetary terms. It can also refer to a specific quantity of time in man hours that must be allocated above and beyond the previously determined quantity of hours required to assure that any overtime or other unexpected hours of work required can be properly compensated for”, says Project Management Knowledge.

When you spend from the Management Reserve, it moves the project completion date out by the amount of time expended. The first step is to get the sponsor and executive management to buy into the idea and agree to support it and follow its dictates. Typical reserves are from 5-15% of the total estimated duration of all the tasks in the project. In complex projects, much of that duration is not known up front. In fact, many of the tasks may not even be known. Even if tasks are not known and hence schedules not known the project usually has a time and cost budget. The time budget is enough to set up the Management

Reserve budget. More uncertainty results in the higher allocations and higher variance of the estimates however.

The most difficult part of Management Reserve is what do you do when the contingency time budget runs out and another change request arises? The process is simple to describe but difficult to implement. Suppose the new change request requires X hours to implement. The sponsor must find some future requirement in the schedule not yet integrated that can be canceled or reduced and replaced with the new change.

Getting the sponsor and senior management buy-in is the most challenging part of implementing Management Reserve.

OUTSIDE THE BOX Forum: Prepare A Seat for the Project Manager at the Strategy Table

Written by Robert Wysocki on July 10, 2017. Posted in Articles. 5 Comments on OUTSIDE THE BOX Forum: Prepare A Seat for the Project Manager at the Strategy Table

The Project Manager has traditionally been viewed as the enabler of business strategy, not as a partner in the development of the business strategy.

I submit that we have sold them short. I believe that a seat at the strategy table can be validated and will be seen to have great business value.

Basic Premise

Outside of the IT Systems Developer, there are no other professionals with as broad and deep an understanding of the business model as the complex project manager. The CIO has had a seat at the strategy table for many years. For some of the very same reasons, the project manager should have a seat at the strategy table in the person of the VP of Projects.

Tara Duggan from Chron agrees, “By focusing on improving customer satisfaction, beating the competition and analyzing market data, strategic project managers ensure long-term success and profitability. Instead of focusing on short-term results, such as meeting deadlines and operating within the budget, strategic project managers have a long-term perspective. They ensure that their project’s goals align with the company’s strategic mission and objectives.”

LinkedIn lists 3,300+ Vice President of Projects job opportunities as being available for hire. It shows the VP of Projects role is critical for organizations to achieve strategic results.

Project Management Offices are growing stronger. According to CIO magazine, organizations have been focusing on expansion and growth of Project Management Offices steadily since 2003. That means the role of VP of Projects is becoming more and more relevant as a leader and strategist in many different industries from manufacturing, healthcare, finance, banking, and service related industries.

The same argument could be put forth for the Business Analyst, but that is for another time and another article.

What Does the VP of Projects Bring to the Strategy Table?

Just as the CIO brings a wide and deep understanding of existing information systems and their potential application across the enterprise so also does the VP of Projects. The VP of Projects brings a wide and deep understanding of business processes, practices and their potential application across the enterprise. In both cases, these potential applications have an intrinsic business value waiting to be applied. I like to think of them as the generalists collaborating with the specialists as together they search for solutions to complex problems.

Advertisement
[widget id=”custom_html-68″]

In the PM times article “Is Your Corporate Strategy A Wishion?”, Fernando Santiagolt Outlines the need for better strategy in organizations, “It is surprising that after almost thirty years of building a body of knowledge in strategy management, with armies of MBA’s learning these principles and many of them working for consulting firms, so many companies get this wrong. When nine out of ten companies fail to implement the strategy, a good part of the problem is that there is no real strategy to implement.”

Having the VP of Projects at the strategy meetings along with the CIO is important. Both these roles can help lead in moving organizations forward by aligning an organization’s business objectives and strategies with strong real-world solutions. The VP of Projects and CIO can do this by capitalizing on their technical experience and business knowledge. Both these roles have both project and operational based experience within the organization that they can bring to the table to form a cohesive, aligned, and prioritized list of projects.

Organizations can be complex. The complexity can make it difficult to align an organization’s strategy. Frequently an organization’s business units have their priorities. The VP of Project role is a strong negotiator and collaborator by bringing business units under one central business strategy.

Larry Myler from Forbes outlines why a common business strategy is important, “There is an often-missing component that, if consistently applied, will dramatically enhance the progression of strategy creation, communication, and execution. That critical element is ALIGNMENT.” Neatly summarized the primary role of the VP of Projects is:

Creation – create a common understanding of the organization’s business strategy
Communication – widely communicate the strategy to make it visible
Execution – ensure projects and programs are delivering capabilities
Alignment – align business units to a common organizational strategy and align programs/projects with that strategy

But isn’t a VP of Projects just as Senior Program Manager? Not so according to James T Brown’s The Handbook of Program Management. The roles of project manager, program manager and VP of Projects are very different in their focus:

Project Manager is a Schedule, Budget, Risk, and Scope focused role. Business strategy is handed to the project manager in the Business Case and Project Charter for most organizations.
Program Manager is focused on the above but in an aggregation of multiple projects. This role also must make tradeoffs to ensure projects are meeting business objectives and expectations. Although this role typically does not create the overall strategy for the organization, as programs are executed they shape that business strategy.
VP of Projects is a role that is looking at understanding and clarifying the organizational strategies and turning them into programs and projects by working with senior level business executives and the CIO. This role is more focused on the creation of the Business Case and Project Charters which will be executed by the Program and Project managers.

What are your thoughts? Does the progression of a Project Managers career go from tactical to strategic? Let me know your thoughts in the comments below.