Voices on Project Management

By Lynda Bourne

Everyone wants to “go agile.” But far too many organizations seem to think agile is simply a different way of doing project work that will miraculously achieve major efficiencies. 

For the approach to achieve its promise, the upper echelons of the organization need to become agile aware and adapt the way projects are initiated, funded and governed so that the project team can optimize their use of agile processes to create value. After all, one size does not fit every situation in an agile world.

I’d like to look at the differences in the management approach that are needed to maximize the value of agile in different situations.

One quick note: Different agile methodologies have different terminology and approaches. For this post, agile is defined as producing an output using a series of relatively short, time-boxed iterations, or sprints, where the work to be accomplished in each sprint is sized to be relatively consistent (e.g., can be accomplished by a team in two weeks), and what is to be done in each sprint is determined during the lead-up to that sprint.

There are three environments where the agile approach can add value:

1. Maintenance environments: In these efforts, the application of agile concepts without the need for project management overheads can be very beneficial. Techniques including small focused teams, short sprints, backlog prioritization, and management. Burn down reporting can show how much maintenance work is facing the teams, the team efficiencies, and the overall backlog trend.

Agile does not need to be embedded in a program or project to be effective. In this situation, the finance and resources (i.e., the agile teams) are the fixed constraints; the organization’s budgeting procedure funds a predetermined level of staffing on an annual basis. The management variable is the amount of work accomplished each month and deals with new and emerging maintenance issues and minor enhancements in a timely manner based on some effective form of prioritization.

2. Contractual or legal obligations: In projects like these, the scope of work is fixed (or at least subject to formal change control) and the management variables are efficiency and cost consequences. In this environment, with adaptation, a whole range of standard project management processes such as earned value can be applied to the oversight of project work and used for management reporting and project control. The agile teams still function in the traditional agile way, sizing the amount of work included in each sprint, producing usable outputs in short intervals and progressively building toward the completed project. The management challenge is achieving the specified scope within the approved time and cost parameters.

3. Projects that lack a defined scope: In these projects, the client often has a vision of what the outcome should achieve, frequently framed in terms of business improvements. In this situation, the project is on a journey to optimize the delivery of as much of the vision as is sensible. The management variables for this type of project include scope, cost and time.

Decisions will have to be made about which parameters are more important—either as an overall consideration or on an element-by-element view of the various components within the project.

a. In some projects, time to market is a key factor, possibly with scope as the second most important factor. And, to a large extent, how much it costs to achieve the necessary scope within the deadline will be a consequence rather than the control. The primary management challenge is delivering the scope required to implement the vision within the time constraint as efficiently as possible.

b. Other projects have the quality of the vision as their primary drive, and the management challenge is to achieve all of the vision for the optimum time and cost outcomes. Decisions on how much and how long can vary depending on progress toward achieving the vision. Obviously, there must be some cost and time constraints. And a key conversation with the client has to be around the value proposition of still achieving their vision based on cost information to date, with the possibility of adapting the vision based on learned experience as the project proceeds.

c. Lastly, in some projects where the available funds are limited, the challenge for management is to achieve as much of the vision as possible within the defined funding limit, frequently with time as an additional limitation imposed by the funding cycle or the market. To maximize value, the client needs to be fully engaged in the decision-making process around scope inclusions, deferrals, and exclusions.

Once you understand the agile framework you’re operating within, the real challenge is making sure your clients and other senior stakeholders also understand that an agile approach to project delivery requires very different governance and decision-making processes. Organizational agility starts at the top by setting the right challenges for the agile teams within the right funding model. The next step is to use appropriate assurance functions to make sure agile teams are delivering what’s needed to create value—old-fashioned budgeting processes are unlikely to be appropriate.

How do you go about engaging your senior stakeholders in this type of conversation?

by Christian Bisson, PMP

A scrum master is an essential part of an agile team. However, it seems their role is often underestimated or misunderstood. In this article I’m hoping I can shed some light on the value they bring.

How People See Them

Here’s what I’ve heard over time:

Elves of happiness

Since scrum masters want teams to perform well, they want to make sure team members are happy. That sometimes makes others think that all scrum masters are trying to do is to make everyone happy without an actual purpose behind it.

Coordinators

Since scrum masters often talk to the team and gather information about the status of a project, they are often mistaken for coordinators—people tasked with giving a status report to the product owner or taking notes during meetings.

Useless

Some people simply have no clue what scrum masters do, thinking they are an overhead that could be removed without any impact because they don’t actually “produce” anything.

What They Actually Do

Help teams grow

One of the scrum master’s main tasks is to educate the team with agile principles, but also to help the team become self-sufficient. In a way, their main duty is to actually become useless as the team becomes more mature.

Scrum masters can do so by sharing agile knowledge and by coaching teams as they go through retrospectives where the team is motivated to talk about how they can improve.

Facilitate anything

There are so many different roadblocks that can reduce a team’s efficiency—whether it’s poorly defined requirements, inefficient meetings, lack of documentation or communication, or conflicts. A scrum master can help tackle anything that might slow down the team.

Keep the focus on the right place

Not being hands-on in projects allows scrum masters to have a different point of view that allows them to re-focus teams when needed. Whether it’s toward the developers and their commitment to the sprint, or product owners and their focus on a product’s vision, scrum masters make sure to remind everyone where their effort should go.

It can be hard to quantify a scrum master’s usefulness since they do not actually produce deliverables. But having experienced an agile project both with and without a scrum master, I can vouch for their role. They bring so much on a day-to-day basis to the teams they work with, which in turn brings quality products to clients.

Have you experienced working with scrum masters? What do you think is most important about their roles? 

By Ramiro Rodrigues

In my last post, I shared tips for closing external projects. Now it’s time to tackle internal efforts.

As part of this discussion, it’s worth remembering that PMI’s A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) does not differentiate between the origin of the customer (internal or external) for the scope verification process.

So even if a project is internal, project managers should obtain acceptance and have at least one approval by the customer in order for the project to be formally closed.

A crucial question to consider: What does your organization's project methodology say? Are you required to get a form signed to show formal acceptance at the end of the project? If so, the good news is you’re closing process is outlined for you.

It gets complicated when you’re not required to sign a formal document or there is no defined methodology for closing an internal project. It creates a great organizational trap for project leaders as projects that are not formally completed tend to repeat the phoenix fable: a project is resurrected over and over again with new work requirements because there is no record of a signed agreement signalling the completion of the work.

Imagine having to re-run a project months—or even years—later when there are no more resources, schedule or budget available to execute the remnants that emerged? On top of this, you’re probably already involved in other assignments, and you may not even remember the full context of that project.

The most effective strategy for not falling into this trap is to produce an informal document of acceptance—a simple text that describes the macro deliveries of the project scope and send your customer a hard copy or email copy. But be careful to include a text that makes it clear that the parties (you and the customer) agree that the deliveries quoted have been made to the desired quality.

And make sure you receive acknowledgement—even a simple “okay” response will be sufficient to file the document and to protect it from unwanted resurrection.

How do you ensure internal projects don’t come back to haunt you in your organization?

By Jen Skrabak, PMP, PfMP

There’s great news for the profession: According to PMI’s latest Job Growth and Talent Gap report, there will be a need to fill 2.2 million jobs globally each year until 2027, growing to a total of 88 million project management jobs in all. Moreover, much of the growth is outside the United States—in places such as China, India, Brazil and Japan. 

Project-related job growth is expected to be 33 percent overall, with health care (17 percent), manufacturing/construction (10 percent) and information services/publishing (6 percent) representing the top three industries.

How can you position yourself to take advantage of these trends? Here are three things to work on.

1.   Get a Certification

Although certification by itself doesn’t guarantee that you will be hired, it does mean that you have demonstrated knowledge and experience in project, program or portfolio management. There aren’t many PMI Portfolio Management Professional (PfMP)^® credential holders out there, so obtaining this certification will help set you apart.

But, instead of viewing the PfMP certification as the goal, plan to take it as a journey. If you find that you don’t have the requisite experience, how can you position yourself by taking volunteer roles to gain the experience? 

Career development should be a joint responsibility between you and your manager. You should express the desire and develop the knowledge to grow your experience in certain areas, and your manager can work to open up opportunities to help you practice your knowledge.

2.   Practice

Work on delivering strategic initiatives, driving change and providing innovation consistently and reliably. It’s not experimenting, but actually delivering—first on a smaller scale, then on a larger scale.

For portfolio managers, for example, you may start by managing the portfolio of a department or product, then move to an entire business unit, segment or product line, and finally on to an enterprise level. 

There are three key areas to grow the depth and breadth of your experience:

1.   Strategic alignment: Go beyond understanding the strategy and proactively work to translate that strategy into specific initiatives. This can be done by defining the business cases, developing multi-year roadmaps or translating high-level concepts into specific projects that will deliver the result, benefit or transformation promised.

2.   Benefits realization: This starts with validating the business case and ownership of the benefits, and is typically realized three to six months after the project/program delivery via operational budget savings, reductions or reallocations. Few organizations realize the benefits because they are often too optimistic in the upfront business case and fail to follow through by ensuring that operational budgets reflect the promised savings or headcount efficiencies. 

3.   Project/program delivery: The foundation of portfolio management is good project and program execution to deliver the product, service or result on time, on budget and per the scope. It doesn’t matter if it’s agile, waterfall or hybrid. Although the portfolio manager may not be responsible for the delivery, the delivery affects the portfolio value.  Ensuring that the portfolio value is realized means ensuring the project or program was delivered effectively and efficiently regardless of the methodology.

3.   Communicate Effectively

Working on the portfolio level means that you’re communicating a vast amount of information—anywhere from 15 to 50 projects and programs—in an actionable way to executives. I’ve had executives tell me, “Don’t tell me what’s going right, tell me what’s going wrong and how to fix it.”  Your role is to remember the four “C”s—clear, concise, compelling and credible. Be to the point, tell the story and build trust with a clear plan of action to fix any potential issues proactively. 

By Linda Agyapong, PMP

I received a lot of interesting feedback on my last post, “What Defines Project Success,” which has necessitated a follow up.

For those who missed the discussion, Aaron Shenhar et al. summarized it perfectly by saying there is no one-size-fits-all definition for project success. Instead, it’s based on the philosophy of “how different dimensions mean different things to different stakeholders at different times and for different projects.”

Every project is different and hence could have different success criteria.  These were the exact same sentiments that folks shared in the discussion on my last post. This time we’ll dissect the concept of project success by breaking down some of the buzzwords surrounding it.

Project managers Jim, Mary and Alex (the same characters from our prior discussion), entered into a high profile kick-off meeting with some Fortune 500 clients regarding an upcoming million-dollar project. When the floor was opened for the clients to ask questions, they unanimously said that nearly 50 percent of the discussion went over their heads because all they could hear were buzzwords.

These buzzwords were “project success” vs. “project management success” and “project success factors” vs. “project success criteria.” The clients could not figure out if they meant the same or not. Let’s help Jim, Mary and Alex break down these buzzwords to their clients based on recent research I performed.

Project Success vs. Project Management Success

Terry Cooke-Davies embarked on an empirical study to identify the factors that are critical in obtaining successful projects after stakeholders had been disappointed with the project results that were being obtained. His study was to address the following three broad concerns:

·         The factors that make project management successful

·         The factors that make projects successful

·         The factors that make projects successful on a consistent basis

Although his three concerns may appear to be intertwined, Anton de Wit provided a distinction: Project success identifies factors that help to attain the overall objectives of the project, whereas project management success focuses on addressing some of the project’s constraints (including time, cost and quality) within the project.

Based on this understanding, Mr. Cooke-Davies concluded that there is a cycle of individual success (such as an individual’s leadership style), which leads to corporate success that later transforms into corporate best practices. As such, once these best practices are consistently applied, it could lead to making projects successful on a consistent basis.

Project Success Factors vs. Project Success Criteria

In their research, Ralf Müller and Kam Jugdev argued that project success factors identify the specific elements within the project “which, when influenced, increase the likelihood of success.” They added that these are the independent variables that enhance the success of the project. And Mr. de Wit described them as “those inputs to the management system that” directly or indirectly lead to the project’s success. (Can you name some specific examples?)

Conversely, Dr. Müller and Dr. Jugdev explained that project success criteria are the measures (or acceptance criteria) by which the final outcome of the project will be judged, i.e., whether the project is successful, challenged or a failure. They added that the project’s success is measured by these dependent variables. (Can you name some examples?)  

So there you have it! Are you enjoying this ride so far?

In my next post I’ll tie this concept of project success to the stakeholder. Until then, I’m interested to get your perspective on this topic.