Skip to main content

Tag: Leadership

The Agile Project Manager—There Can Be Only One!

drew1I hope I’m not the only reader who remembers the Highlander movie & television series. Duncan McLeod was an immortal amongst others who was fighting to be the last remaining immortal. In each episode, there was inevitably a decapitation or two as the immortal population was reduced to the final one.

I use the symbolism of the Highlander to remind me of several aspects of agile project management. The first relates to focused teams and our earnest effort to reduce all levels of multi-tasking.

The second reminder is what I want to explore here—the notion of investing in a single team to create a working model for your agile adoption efforts.

This isn’t just any team. It’s your example team; a high performance agile machine that illustrates sound principles and delivers on the promises of agility. It’s a role model to other teams and proof that you can be agile in your specific organization & culture.

I have a bit of “mad scientist” in me and this is the team you experiment with in trying out new and novel approaches for your domain. It’s the first team that moves from Scrum to Kanban. Or it’s the first team that tries out Cucumber as a Behavior Driven Development mechanism, while including the whole team in crafting acceptance test driven automation.

Let’s explore some of the characteristics of this singular example agile team—

Let’s first explore what the team isn’t…

The team isn’t composed of special developers, the “best of the best”, or full of themselves ego’s. Yes, you might have some more seasoned folks on the team, but in ratios that are representative of your other teams and overall population.

The team isn’t paid a premium wage or compensated in some special way. In many ways they represent a cross-section of your teams in experience levels and compensation structures.

The team isn’t isolated from challenges such as interruptions, multi-tasking or dealing with unkempt legacy code. They have an equal dose of the challenges facing every other team.

And finally, the team isn’t placed on a pedestal for everyone to see. Yes, it’s your example team and the one that illustrates the best properties and practices of your agile adoption and progress. But, they’re also just another team and virtually equal to everyone else.

drew2

What the team is…

If you buy-into creating a model team, it’s sort of hard to figure out what that might “look like” in the wild. While I don’t want to give you a prescriptive list like, do these five things and a magical event will occur creating a perfect model team, there are some hints I want to provide for some behaviors and practices that you might want to model for.

Locale

The team is co-located and cross-functional. If at all possible, they sit together at one large table and work around and across from each other. Their room has white boards and plenty of wall space for information radiators that are meaningful to the team

The team has some privacy—being located in a conference room or other walled in area. They’re insulated from random noise and interruptions that might result from too open a space. I’ve often used the term “Team Room” to describe the room dynamics.

The quarters are relatively tight—in that everyone in the room is working closely together. Everyone can hear every conversation that is going on in the room. If someone is working remotely or on the phone, the room can hear the interactions.

I often get the question of whether you can leverage distributed or remote team members as part of your model team. I think the answer is normally yes. But what you want to do is allow budget for travel, training, and tooling that supports bringing your distributed team together as much as possible—both physically and virtually.

For example, when you’re initially forming your team, it’s a really good idea to bring everyone together for some initial introductions, training, and team-building. How else would you form a high-performing team?

Smells

An often used term is ‘smells’ with respect to agile teams. These are patterns or trends that one observes when collaborating with the team. Here are a few examples—

There’s a buzz in the room, it’s rarely the case where everyone is quietly working. Instead, team members may have headsets or earphones that allow for a sense of quiet if they need to “get away” for some private work.

Work is done primarily in pairs. Not restrictive rules such as—you MUST pair at all times. Instead, it’s a more natural and organic level of pairing—as it makes sense, in small groups, based on the dynamics of the work. And everyone on the team pairs in one way or another!

There’s quite a lot of dynamic discussion going on in clusters. A lot of white board conversations. And every conversation ends up moving over “working code” as the final arbiter of discussion and progress. So—hovering around screens and talking about software design, behavior, adjustments, failing vs. passing tests, bugs, etc.

A final smell might be chaos. I like to describe agile methods as being an “uncomfortable” methodology. They are quite strict focused towards specific practices and there’s an overwhelming sense of “controlled chaos”, especially if you’re part of a well-performing agile team. Point being—it’s not totally scripted. Discoveries happen. Plans change. Adjustments need to be made. And everyone quickly adjusts and moves on. The goal that the team has committed to for the iteration or sprint is the thing that keeps the train on the tracks, with everyone focused towards meeting that goal.
drew3

 

Throughput & Swarming

I get asked this question all of the time—can the developers move ahead of the testers on the team during a sprint? This question implies a distinct separation between development vs. testing work and aligns work done-ness along skill & functional boundaries.

My answer is always the same—no!

The team shouldn’t get “partial credit” for development-done work. In fact, they should only get credit for done-done-done features & stories that are complete, meet acceptance criteria, and are completely demonstrable. Given that definition, then teams would be better served to swarm around their work, limiting their stories in-progress (Work in Progress or WIP) and getting their work done as soon as possible.

In fact, this isn’t an ‘option’, but the way in which well-performing and mature agile team should naturally behave. They understand that throughput (the time it takes to move a story from start-to-finish) matters. And that team collaboration around getting small sets of stories done as soon as possible (swarming) is the best way to do this.

In my experience, it’s a whole lot easier to talk about this than it is to deeply instill these behaviors in agile teams. This is why you’d want to “get it right” in your example team—to discover the best ways to influence this wonderful behavior.

Quality

It’s hard for me to explain the myriad of ways that quality activity needs to change in order for a team to truly become high-performing. The first characteristic might be everyone on the team understanding that you don’t test-in quality…you build it in.

Just the other day a colleague asked me what I thought were the highest value quality practices that influenced agile high performance. Perhaps sharing my reply would help. Here is the list of high-impact practices that I sent him and that I think are reflective in an outstanding agile team—

  1. Fostering a whole-team view towards Quality—moving testers to the front of the line in that they collaborate on the requirements and getting the solutions ‘right’.
  2. Pairing in general: pair-programming, pair-testing, triad-pairing (developer + tester + product owner), paired code reviews, etc.
  3. Having the ability, willingness, and aggressiveness to stop-the-line and apply corrective action(s) immediately.
  4. Test planning on an iteration & release basis while initiating whole team collaboration around strategies for what & how to test.
  5. Applying exploratory testing in a paired fashion, leveraging session-based (charter driven) exploratory testing across teams.
  6. Performing active agile release planning so that teams gain a broad view towards dependencies & integration—including a DevOps mindset or continuous deployment (CD) view.
  7. Naturally applying Unit Testing / TDD (Test-Driven Development) techniques within teams.
  8. Naturally applying ATDD / BDD (Acceptance Test Driven Development / Behavior Driven Development) – driving Triad collaboration & conversations around. The focus here should be collaboration first and automation second.
  9. Properly preparing for and conducting powerful sprint reviews or demos that engage stakeholders and customers to provide active feedback.
  10. The Mike Cohn / Agile Test Pyramid strategy works…so leverage it; includes the notion of multiple tools and layered approaches

The list is in priority through the first three quality differentiators. Beyond those, they’re not in any particular order. You might not need to apply all of these approaches to achieve high-performance, but the list does imply some of the breadth and depth to a set of effective quality practices. And I hope that I didn’t imply that “testing” was equivalent to “quality”.

Micro-Adjustments & the Stand-up

One of the most misunderstood aspects of agile team is the nature of the teams’ commitment to a body of work in their sprint and then gathering daily to discuss their progress in the daily scrum. You quite often see teams look at their sprint plan as being a fixed set of user stories and their associated tasks. They commit to these ‘cards’ and work diligently to execute to their plan.

Many teams allow their traditional planning instincts rule too much within their sprints. You see the tasks and stories should only be a means to an end. The Sprint Goal is what the team commits to and in the daily stand-up they should be discussing progress-to-goal. And anything that comes up that—

  1. Impedes or blocks achieving the goal
  2. Provides new information that adds, changes or removes work to support the goal
  3. Leads to discovery that influences interpretation of the goal—refactoring, under/over estimation, interruptions, skill gaps, etc.

should be the real focus of the team. And in the daily stand-up, the discussions should surround what I’ll call the micro-adjustments that an agile team makes each and every day.

These adjustments are goal-based discussions between the team and the Product Owner surrounding goal achievement. Often, they require thinking around changing or jettisoning agreed upon scope within either the sprint or ultimately the release.

These are healthy discussions that get to the root of the agile methods “just enough” and “simplest possible solution” lean principles. Moving from a follow-the-plan focus towards a collaborative, micro-adjustment focus is one of the hallmarks of a high-performance team—an agile team that focuses on solving customer problems via their goals.

Wrapping Up

One of my personal improvement reflections in many coaching gigs is not establishing a ‘model’ or ‘example’ team quickly enough. It’s usually driven by my need for an example that illustrates good agile practices from the same context that we’re initiating agile adoption—one that I can “point teams towards” so that they can view an approach or technique beyond my just talking about it.

Brian Marick is a well-respected agile testing consultant & coach. Brian often speaks about the power of an “Example” and will often ask for one—an example for a User Story, an example of an Acceptance Test, an example reflecting the customers problem, an example of a design you’re discussing, etc. He even has gone so far as to name his website www.exampler.com. Brian is a firm believer in examples being a wonderful communications device to focus dialogue towards solutions. I agree.

So is the point of this post to create an example team and then be done with it? NO!

It’s to create a model team as part of your agile transformation and then leverage the knowledge gained from them to improve your overall adoption approaches, techniques, and tools so that your consistently raising-the-bar and improving. A team that you can adapt with and learn from, one that is strongly embedded in your organizational culture and problem domain, and a team that can help guide your evolution…simply by example.

Thanks for listening,

Bob.

Don’t forget to leave your comments below.

How to be Comfortable with Escalating When Work is Not Being Completed

FEATUREJune6Getting the Most from Your Project Staff
Part 2 of a 3 Part Series

 


As a Project Manager you are tasked with getting work done through others. It may seem simple, after all these individuals are assigned to the project team and just need to do their job. But this is not reality.

What is reality is that project resources are often assigned work beyond your project and may even be involved in other projects. It is typical in the popular matrix project organization that team members do not report directly to the project manager, but rather a functional manager. This makes it even more important that the project manager have the skills to get work accomplished through others. Even the most experienced project managers continually report this as one of their top challenges.

In this three part series you will learn techniques that will maximize your ability to get the most from those individuals assigned to your project. The strategies presented will provide a solid approach that can be used immediately with your team.

  • Part 1: Tips to gain commitment from your project team
  • Part 2: How to be comfortable with escalating when work is not being completed
  • Part 3: Strategies to improve communication and follow-up to team members

This article should really be titled ‘How to be comfortable with escalating when work is not being completed or not completed as expected’

Good news! You’ve already started! If you’ve followed the strategies in Part 1 of this series, “Tips to Gain Commitment from Your Project Team”, you already have agreement on expectations for your project resources. In a perfect world, everything will go according to plan, but it is not a perfect world and there is a chance you will run into ‘imperfect’ situations involving team members.

This may include such things as work not being completed on time (particularly critical path tasks, issue resolution, and those that are predecessors to other work), status not being reported, meetings not attended as expected, or lack of participation.

The steps outlined below will help to guide you through the escalation process.

STEP 1: Determine the impact

1. Judge the degree of impact

  • Is it behavior or actual work not being completed?
  • Is this an early warning sign of things to come?
  • What significance will this have to the project?
  • How will this impact other team members?

2. Obtain clear examples and impact to the project

  • Be specific to the project work and not to the person.

STEP 2: Discuss the situation and impact with team member

  1. Review the agreed upon expectations
  2. Determine, with the individual, if there a reason and how you can help initiate change to rectify the situation.
  3. If the reason is related to the person being overwhelmed with other work, offer to change expectations to accommodate, if the individual can agree to meet requirements and it is acceptable. Indicate that you will help by discussing the situation with their manager so that the manager can initiate change
  4. If you are not having success resolving with the team member, let them know you are concerned with their availability and that you will be discussing the situation with their manager.

STEP 3: Escalate

1. Formulate and document examples and the results of your discussion with the individual.

2. Contact the manager

  • State the examples and recommend actions (corrective and preventative).
  • Utilize the schedule to demonstrate tasks and dates and the staffing plan for the individual’s responsibilities.
  • If work needs to be completed, state dates and be clear that the manager is responsible for seeing that the work is done by that date.
  • If there is a resource availability issue, expect the manager to resolve this by replacing the individual, freeing up other work, offering a backup, etc.
  • If behavior needs to change, communicate your expectations.
  • Follow up any conversation immediately with an e-mail stating expectations and dates.

3. Follow-up

  • Follow up if change has occurred or work has been completed, be gracious!
  • If work not completed escalate to the project sponsor or senior leader of the project.

4. What? You want me to tell on someone?

  • No, it is not telling! Your job as a project leader is to assure the work is completed on time and as expected. It is your responsibility to judge when this will not occur and make every attempt to keep the project on track.
  • You have no choice but to escalate if work is not being completed on schedule.
  • Using leverage from your project leadership can help resolve staffing problems, or recognize the issue and adjust the project expectations or deliverables.
  • If the team member is burdened with other work, you will be helping them by trying to elevate the problem. Make that clear to them.
  • Setting this standard will help build future commitment and expectations.

5. Rules! Yes, there are rules… sorry.

  • Business policy is primary, then project policy.
  • Only discuss the problem, not the person.
  • No surprises: Notify those involved as to your next steps.
  • Notify your management before you escalate to a team members manager.
  • Document your examples, conversations, and resulting commitments.

Don’t forget to leave your comments below.


 

Why is Benefits Management so Hard to do?

Almost every company accepts the need to manage project benefits, but very few actually do it!

Earlier this year, I started a discussion and poll on the topic of why benefits management is so hard to do. The response was intense, with over eighty-two PMO managers, consultants and professionals related to the topic. This article summarizes and comments on these responses and draws some conclusions.

The poll asked respondents to select one of five causes why benefits management is so hard to do. The results of the poll follow. This article will be structured around these five potential causes and, of course, as one respondent suggested, all of the above may be the winner.


fernandjune61

No defined governance around benefits

Not surprisingly, this was the clear winner, as these are PMO-related professionals and the second word PMO people say when we wake up in the morning is probably governance (I will leave the first to your imagination). Governance structures for portfolios, programs and projects in most organizations have been designed to execute projects and deliver outputs, not deliver benefits or business results. No different than other areas, governance for benefits management should include guiding principles, definitions, roles and responsibilities, processes, templates and tools.

Let’s see what we got from the discussion.

As a starting point, Benefits Realization Management needs a business case on its own, as it requires resources. As Bruce Bozza, PMO/PM at Fujitzu in the UK states, “BR is a management process … it takes resources to effectively implement. It is not a magic wand. Its asserted value will challenge many senior managers’ mindsets. It can only be optimally implemented with appropriate sponsorship (top down) and associated governance.” Bruce touches on two key areas: resources and attention. Resources will be needed, probably dedicated, to implement BR. Second: attention from key executives and managers to participate in the governance bodies required to make BR work. So there is a cost — what about the benefits? If we consider that 20 to 40% of investment in IT is wasted every year (Gartner, IBM), decide where your organization sits compared to the norm, and then do the math with your yearly portfolio budget, and there is usually enough room to give BR a serious try.

“Cost/benefit do change depending on the market conditions, but some managers don’t want to do this analysis because of fear. If their pet project fails the analysis test, their position is at stake,” says Ravi Shankar, Senior Consultant at DWS, Melbourne, exploring the governance topic of periodic reviews of business case, as conditions usually change. In addition to fear, I would add that updating a business case because of market conditions is seldom a priority because there is no trigger. The only way to avoid this is periodic reviews, in addition to stage gates at approval, delivery, etc. The only exception to this is changes, which do have a trigger. The problem, as Linda Watts, PM at Coop Bank in the UK states, “The impact of changes to a project are not always managed against the impact of this against the benefits.” In my opinion, not always is very generous, as it is very seldom that changes are assessed against the business case. Of course, that only material changes are relevant, but not assessing changes against the business case misses the opportunity to ask an excellent question: when a change does not impact benefits, why are we doing it? Of course, there are always good reasons, but it is a good question nevertheless.

One of the main barriers regarding benefits realization management, particularly in IT, is that business resources — those that realize benefits, are not usually under the influence of a PMO. On this topic, Gillian Milne, Head of the PMO/CMO at Rand Merchant Bank in Johannesburg, South Africa, says, “However the PMO is often best placed to track what has actually been done against what was expected. As soon as benefit tracking is embedded more benefits are realized due to the focus, and business cases become more robust.” As Gillian puts it, a mature PMO is likely the best organizational unit to take the challenge of benefits realization, which cuts across organizational barriers, as long as there is a strong mandate and clear governance supporting this effort at the enterprise level. Success in this area can naturally position a PMO to evolve into an SMO or Strategy Management Office, focused on the execution of strategy, not just delivery of projects.

“Let’s be honest: PMOs have struggled with converting benefits realization from a concept into reality for a long time now,” says Calum Robertson, Principal Portfolio Analyst at Auckland Council, New Zealand. Calum is recognizing the need to do something different and provides concrete recommendations: “Change in culture from thinking about projects to thinking about investments. Projects are expected to be completed ‘on time, on budget’ but investments are expected to yield a return.” Calum hits on the focus on delivery that has driven most PMOs, with a narrow view limited to the triple constraints and with little or no attention to benefits. Strong governance and sponsorship is required to implement this cultural change. Another topic Calum hits is the need for accountabilities that transcend project closure, “Maintaining the project spotlight (and dashboard reporting) beyond project closure.” As soon as projects are delivered, they disappear from the radar screen, and benefits promised for upcoming years are very seldom considered when analyzing the impact of most recent projects. Again, this points to resources and tools to do it properly, but can we afford not to and remain flying blind on benefits?

Benefits are not standard or comparable

While this cause received 22% of the vote, there were very few comments in the discussion. In a way, it is related to governance, which should define standards for calculating benefits so they are comparable across investments. This requires a framework for benefits realization that includes not only the calculation of benefits, but definitions and rules that determine when a business case is needed and the rigor and detail required, depending on the type of investment and freedom to invest. For example, an infrastructure project required to replace obsolete technology or a legislated change have little or no freedom to invest. On the other extreme, a venture usually has high freedom to invest and requires more scrutiny and higher returns.

Fiona Binney, RM at Intergen in New Zeeland, expands the discussion into the topic of tangible VS non-tangible: “First they need to be identified as tangible or non-tangible, the tangible ones then need to be baselined as mentioned above, and they also need to be assigned to a benefits manager who will be responsible for reporting on the delivery of these benefits for a dedicated length of time.” It is clear that tangible benefits should be the ones subject to measurement, but non-tangibles, like customer satisfaction, employee morale, etc., can still be assessed.

Joe Lunn, Portfolio Manager at Zurich North America in Chicago, expands the categories for benefits: “We segment benefits into 1) hard, 2) quantifiable soft and 3) qualitative categories and provide sponsors and project teams with definitions and monitor submissions to assure accurate use of these definitions.” I want to direct your attention to the term “definitions” as they are integral to make this approach successful, and again, strong governance is required.

Even within the same type of investment, the estimate of benefits should be comparable. As a simple example, if two projects are projecting savings on production costs for product A, as a minimum they should use the same production forecast for product A, and you would be surprised at how often this is not the case. Referring estimates of benefits to units of output is always a best practice, as projects either increase these units of output (increase revenue) or reduce variable cost per unit. Only fixed costs are different but usually easier to verify. Once this is done, the next step is to define standard formulas that make all the assumptions explicit. As an example, for headcount reduction you need to specify not how many people you will reduce, but the change you are expecting in units of output per person, what the current units or baseline is and the average loaded cost per person. This way, your estimate does not depend on whether sales go up or down, or whether salaries go up — there is no place to hide.

Jodelen Mitra, PM practitioner from the Philippines, summarizes this topic very well: “If the logical framework has been well-defined from the beginning and the performance plan where indicators and targets developed, then benefits management will be easier.”

Accountability for benefits is misplaced

This cause came third at 19.5% of responses, very close to the second one, and is at the core of this discussion as the issue of accountability for benefits lies on the frontier between the service provider, likely an IT department, and the consumer of the output of the project, likely a business unit. When a business case for a project is created, it usually involves the participation of business resources, which provide the projections and assumptions regarding benefits. At the end, it is the business case for the project, and the project manager may end up accountable for delivering benefits on which s/he has no control.

On the topic of accountability, Ben Reardon, Senior Project Officer at the University of Western Sydney, Australia, says, “So often as project professionals, we focus on a variation of ‘on time, on scope/quality, on cost’ that we forget that the measure of what a project is for is how (and how much) it delivers benefits.” Here, Ben is opening a discussion on the two dimensions of accountability for benefits: one is to measure and the other is to realize the benefit. The former requires skill to define the metrics and collect measurement, and the delivery organization is likely better prepared to do this than the business. For the benefit itself, it is clearly the business that is accountable, the sponsor, manager or executive who pitched the project.

Emphasizing the need to see projects as investments, Steve Prothero, Principal at True to You, Camberra, Australia, states, “It is a combination of lack of ownership (i.e., it is not my ACTUAL money) so there is a level of abstraction that is compounded by lack of knowledge of IT.” And Bruze Bozza complements this discussion with a suggestion to make money real: “Enforcing accountability and linking rewards will help generate the business culture change required at senior levels.” Linking rewards to achievement of business benefits is probably at the top of the maturity scale for benefits realization management. The problem is to get there without this link, as money in a business case is not real, many projects can claim success over the same benefits, as there is no way to reconcile what all the different projects are promising. In a consulting engagement a few years ago, I reconciled all the promises for productivity improvement that had been made, and they represented savings sufficient to reduce the workforce by 45% and, of course, not a single person had been reduced. Because business cases are done in isolation, there is no ceiling for what can be promised, outside of sanity, that is.

To round up the discussion on accountability, a framework for benefits realization management needs to assign accountability at three levels:

  • Project Managers are accountable for delivering capabilities
  • Program Managers and Business Managers can be accountable for delivering business outcomes
  • Executives are accountable for the link between business outcomes and financial results, because this is, in essence, the strategy of the business, which should consider all the external forces.

Under this framework, the frontier for accountability resides with the business outcomes (i.e., number of repeat customers increased, hours of truck utilization increased, traffic through Internet site increased, etc.). It is the executives who, in their strategy, make the connection between these outcomes and the financial results of increased revenue, reduced cost, etc.; only they can be accountable for this. The rest of the organization is accountable for delivering to these business outcomes, which also happen to be the usual performance metrics the organization already tacks. This way, benefits realization management can be done in a way that assigns accountability where it belongs and leverages existing metrics.
Unrealistic business cases

This cause came as a distant fourth with 14.6%, but this could be related to the fact that governance, accountability and business cases not comparable are all related to unrealistic business cases. In other words, with strong governance and clear accountability, people would be more careful when making promises for benefits. If the checks and balances and process are not in place, business case money is free!

As Linda Watts states: “Firstly the benefits that are identified at the start of a programme are often hypothetical figures stated by an Exec team who are not close enough to the detail to be able to validate. This leads to a lack of buy-in from individual teams who are left to deliver them.” In the executive suite, estimates for benefits tend to be high level and generous, particularly when it comes to pet projects. Then these estimates of benefits are passed to a director or manager in the business who rarely buys in or feels accountable for those numbers.

On the topic of accuracy, business cases tend to be completely disparate. On one hand, the estimates of investment are usually detailed because this is something we do well and have information for, so we take it to a level of accuracy that does not correspond with the estimate of benefits against which it will be compared. Estimates of benefits are, by nature, nothing more than an educated guess. Joe Lunn brings the idea of stage gating to the discussion: “One way to assure greater accuracy of benefits targeting is to revisit the benefit estimate originally presented during project approval at least two more points in the project lifecycle. First is after requirements are completed. Reassess whether the original benefits can be achieved given these requirements. Second, assure that contractors or vendors performing development work understand the targeted benefits and indicate comfort that their development work will contribute to achieving these.” When stage gates for the business case are defined in advance, sponsors tend to be more careful with the initial estimates, as they know they will have to defend them at later stages. When this is not the case, they will try to make the business case as attractive as possible to get the project approved.

Benefits are not verifiable

This cause came last with only 7.3% of responses. However, most of the discussion had to do with this topic, which, in my opinion, is at the core of the inability of organizations to implement benefits realization. Let’s look at the discussion:
Kik Piney, Professional Training & Coaching Consultant and Contractor in France, brings the complexities of causality into the discussion: “Benefits are badly managed because there is no agreed way to manage them well — because there is no effective mechanism for measuring progress towards achieving them. This statement needs a bit of explanation. As a starting position, it is useful to clarify some PMI concepts: PMI talks about ‘benefits realization’ in the Standard for Program Management. However, what a program provides, at best is ‘benefits enablement’ — i.e., a change to the operational environment which should contribute to improving business success. So what does this mean? Consider the central benefits planning analysis tool: the ‘outcome map’ that is designed to map from deliverables to outcomes, and from outcomes to benefits. This can be envisaged as an ‘if-tree’ in an ‘assumptions forest’:

  • if we can create the (project-related) deliverables as defined,
  • and if they can be used to generate the outcomes in the outcomes map
  • and if the outcomes would enable the realization of the forecast benefits, then,
  • assuming the business environment is still as expected in the initial analysis, we should be able to achieve the predicted result. This means that, until it is too late, there are no reliable means of tracking progress towards success.”

The need to understand and manage the relationships between projects, outputs and outcomes, as stated by Kik, clearly explains why the traditional approach of ranking business cases only makes sense in an operational scenario, where there is a direct cause and effect relationship between projects and some financial return, like reduce a certain cost. In today’s world, most organizations are in a transformational/adaptation scenario, where capabilities (usually output of projects) have to integrate with others before generating business outcomes.

Kik also mentions the forest of assumptions, and these imply risk. We are very good at estimating delivery risk, but what about benefit risk? When the causality relationships are compounded with delivery and benefit risks, it is easy to understand why organizations shy away from benefits realization management, as it looks too complicated, and traditional portfolio management applications do not tackle these issues.

Bruce Bozza complements the discussion: “Sound BR does not just involve defining the end benefits and measures … critically it requires understanding and measuring the lead indicators to outcome/benefit generation to enable corrective decision making in a timely manner. Similarly, it requires an understanding of the component relationships and interdependencies … e.g., what if I stop A, what if we speed up B, where to cut funding in bad times, and so on.” The concept of outcomes as leading indicators brings the whole topic of benefits realization closer, as programs can be defined around business outcomes that represent leading indicators. For example, a program could be defined to reduce the cycle time for preparing a proposal, a business outcome that can act as a leading indicator for another business outcome: percent of proposals won, a lagging indicator and definitely a good predictor of revenue increased, a financial outcome. Once again, this reinforces the need to understand causality relationships.

The achievement of financial outcomes, even business outcomes, usually depends on many streams of causality, which make the estimation and the verification of benefits impossible. Gregory Ellis, PM at Dell, Japan, says, “It’s all the talk these days about how PMOs can no longer satisfy themselves with delivering specific business requirements on scope/budget/schedule, but have to take ownership on the business outcomes, blah blah blah. Baloney. This notion fails because of the same reason that attempts to apply Six Sigma to project management fails: there are too many uncertainties and variables at play to offer concrete visibility and control. Did the Sales department’s revenue increase 20% last quarter because you deployed the Sales Force Super-Duper Empowero-matic, or because of the staff augmentation and new Center of Excellence training program that HR implemented, or because of the flex-time, or because of Product Development’s unveiling of a popular new wammy-jammy that captured market share? Ugh … maybe all of them? None? It’s a pipe dream that the Board has thought up because it wants concrete answers on whether its investments are providing raw, bankable value, and a dream that is not rational.”

One more element in this discussion is the topic of baselining. Kiron Bondale, Project Portfolio & Change Management Practitioner in Toronto, Canada, states: “Oftentimes, no baseline exists against which to compare the benefits. In such cases, the project should be responsible for identifying the appropriate metric, gathering a baseline and then delivering benefits against that baseline.” Everything in benefits realization management is incremental, cash in and cash out should be the foundations of a business case, and if there is no baseline, verification of benefits cannot be done.

Conclusion

The compilation of the different points of view regarding why benefits management is so difficult to do seems to converge in two main conclusions:

  • Strong governance with clear accountabilities and a defined framework are needed, and this has a cost that is not trivial
  • There is an intrinsic problem in measuring and managing benefits due to causality relationships that makes it difficult, if not impossible, to do

The first conclusion was easy to anticipate. The second points to the need for innovation and to do things in a different way. There is basically one way of doing portfolio management, and it doesn’t work most of the time. There is a parallel to the use of waterfall in the past for every project. It worked for some of them, but it never worked for those projects with high volatility and uncertainty, in which creating a schedule or trying to manage from it was an exercise of futility. In a similar way, there is a need to do things in a different way in benefits realization, because the current approach, which was developed for a more stable environment where most projects were operational in nature, is no longer the norm but the exception. Throwing governance on top of an approach that doesn’t work is not going to make things better; on the contrary, it will highlight the shortcomings and put the whole concept of benefits realization management at risk.

The main points from this discussion have also been used to produce a short video called “Benefits realization, the problem to be solved”: This video also includes an alternative approach: top-down portfolio management, which I have proposed in other articles, in which benefits are estimated at the portfolio level and as a result of the implementation of a strategy or plan. These benefits are then allocated based on the relative contribution of each initiative to the intermediate and final results. In this approach, benefits realization is focused on the achievement of business outcomes, which are more tangible and easier to measure, making benefits realization more effective and easier to implement.

To summarize, the area of benefits realization management is an accepted concept in most organizations, and sometimes even a mandate for heads of a PMO. However, there is a gap between intention and execution. Throwing governance behind this could make things even worse. The reality is that until the intrinsic limitations introduced by causality relationships are addressed, this endeavour will neither be realized nor beneficial.

Don’t forget to leave your comments below.

Project Management Considerations for Specialty Software Implementations

In addition to upgrades and enhancements to their flagship ERP solutions, for a variety of reasons companies may also turn to specialty software companies for solutions to business problems. The rationale for using specialty software products can vary from filling gaps in their solution portfolio, gaining a competitive edge or responding to an outside factor such as new regulation.

Although these specialty software solutions are smaller in size and scope, they do require a relative measure of project management consideration. Many times I have seen dismissive or optimistic project managers assume that because a solution is smaller in size and scope, one can take a very relaxed approach to the implementation life cycle. In fact, greater care than what is found on ERP implementations needs to be emphasized in certain areas of the project.

Specialty software companies are hotbeds of innovation for emerging technologies, applications and interfaces. They bring to market solutions that can play a key role in creating a competitive edge or other differentiation for their customers. Compared to ERP solution companies, specialty software companies are smaller and typically less mature in certain areas. While this environment can make for innovation and agility, it can also create an expectation gap when comparing other specialty software functions against ERP solution companies. As mentioned before, one of the greatest mistakes a project manager can make would be to have the same level of expectations that one would have with an ERP solution company. In addition, it is just as equally dangerous based on their relative size to rationalize the project management to a minimum; treat the specialty software company as if it is “shrink-wrap” software, a “black box” integration or external database.

Below follows some project management considerations that have worked well when leading specialty solution projects:

kevinjune61

Early Engagement Of Leadership — As with ERP solution projects, it is equally important to map all of your stakeholders, including those from software companies. What changes with specialty software company stakeholders is that the organizational level of interaction becomes much higher. While it is unlikely that you will ever meet the CEO of an ERP solution company when leading an upgrade project, it is very likely that you will meet the CEO of a specialty software solution company, especially if you may turn out to be their largest customer. Early on in the project be sure to create a mutual leadership “gear-mesh” whereby your CIO is connected with their CEO, Project Director connected with the head of their Product Development team, etc.

Mutual Success Criteria — As part of building the mutual leadership “gear-mesh,” a key deliverable will be the creation of mutual success criteria. Before purchasing the first software product license, it is very important for both the customer and specialty software company to make visible what they stand to gain with the implementation. In addition, this understanding of mutual success criteria also helps to shape the commercial agreement between the two companies. An example of mutual success criteria appears below:

Acceptance Criteria — From the definition of mutual success criteria, the next key step is to define how the specialty software product is accepted. With ERP solution companies, it is important to define the functional performance, physical performance and support performance criteria crisply. This has the double benefit of not only ensuring the customer gets what they need but also makes very clear what the specialty software company needs to achieve on the path to success. This step is also critically important if you are to be the largest customer of the specialty software company.

Customizations — As with ERP solution companies, specialty software companies build products for markets, not specific customers. It is tempting to pursue a path of deep product customization as the specialty software company may be willing to do anything to service a new customer. In addition, the customer may perceive that the specialty software company will be more agile and able to deliver a product tailored for a specific customer. As with any type of customization, the project manager needs to be realistic as to what level of customization the specialty software company can realistically deliver.

Product/Solution Resources — ERP solution companies have a lot of resource depth built up over the years for their products. In addition, they have structured training programs for their employees as well as customers. However, that may not be the case with the specialty software company as it may be that only a few people know the inner workings of the product and/or have implementation experience. In addition, a project manager may assume that the same level of resource depth occurs as with ERP solution companies. The project manager must recognize these differences and act accordingly by employing such methods such as asking for and interviewing named resources to be committed to the project.

Testing — As mentioned before, all software companies build products for markets. When it comes to testing, even greater care must be exercised from a project management perspective to ensure success. If you turn out to be the largest customer of the specialty software company, it is unlikely that the specialty software company has the testing cases and performance testing environment needed to support your implementation. As a project manager, promote open discussion and examination to determine the level of rigor of testing capacity in place as well as the path to close the gap required for success. Conduct this effort very early in the project to allow enough lead time for the specialty software company to build the necessary capacity for the upcoming testing phases. In addition, make the specialty software company a key stakeholder when it comes to the definition of the system, performance and integration testing phases.

Estimating — ERP solution companies have a long track record of implementations that builds a credible history of assumptions and risks for estimating your project. However, that may not be the case for the specialty software company that might have a limited number of implementations of your size and scope. As a project manages, you should adopt the same top-down and bottom-up estimation for specialty software companies as you would on larger projects with ERP solution companies. In addition, take into consideration that while a specialty software company may be very agile and innovative from a product perspective, that may not be true of delivering releases, customizations or post-implementation support processes. Take the same level of attention as well as reasonable expectations for both base effort estimates as well as lead/lag times with deliverables.

In summary, it’s very tempting to size both the amount of project management effort and skills relative to the size of the specialty software company. This has a number of inherent dangers given some of the delicacies that apply to specialty software company considerations beyond the power of their innovative products. It is wise to apply the same ERP solution expectations, doctrine and methods with specialty software companies to avoid future pain when it comes to testing, implementation and adoption of these solutions.

Don’t forget to leave your comments below.

What are the Top 3 Obstacles in Projects?

FEATUREMay23rdWhen I spoke at the Project Managers SIG in Silicon Valley recently, we spent the majority of the time talking about overcoming obstacles.  Upon returning, I faced several new obstacles in a construction project I’ve been coordinating, and so I’ve been thinking of the critical importance of overcoming obstacles.  Obstacles are common in any project.  Thus, how effective a project manager is at overcoming obstacles will largely determine success vs. failure.

One of the keys to overcoming obstacles is to think about potential issues that might come up down-the-road……NOT to become a negative complainer (so let’s not go down that road!) but to be better equipped to surmount them.  In order to best address this topic, I’ve compiled obstacles from my clients, personal projects, speech participants etc. and have identified the top three: 1) Lack of clarity.  2) No Time to Rally.  3) Priority conflicts.

  1. Lack of clarity:  It is amazing how often the project teams I work with can quickly achieve success by stepping back and thinking about the basics.  What is the goal?  Why are we focusing on this task?  What will really matter to the end results we intend to achieve.  It is hard to succeed when you don’t have a full understanding of the project.
    In the last 15 years, there’s been a tendency to add complexity to projects.  For example, we typically want to implement the latest and greatest functionality in our ERP systems; however, I often find we haven’t fully thought through the effort involved vs. the benefit or the timing of implementing these types of changes.  Often times, we can achieve the same benefit through a simpler approach and save the extensive resource needs for when the functionality warrants the investment.  The same theory holds true in countless situations.
  2. No Time to Rally Support:  Do you need the support of your team?  How about project sponsors and top leadership?  Of course!  Yet it is not always easy to find the time or simple to ensure your project stands out in the crowd.
    With your project team members, consider the following tips:  Make your project an object of interest.  Create a buzz.  Why would people want to be on your team?  Be the type of leader where everyone fights to be on your project.  Don’t be fooled.  You have competition even if your project is a “required” part of your team members’ responsibilities.  How will you stand out in the crowd?  Let your personality show. 

    For project sponsors and top leadership, you must relate your project to VALUE.  How will it help achieve company objectives?  How will it help individual leaders succeed in the organization?  Be visible and promote your project.  Relate it to improving customer service levels, speeding up results, increasing profitability etc.  Soon you’ll have an overwhelming number of offers for support.

  3. Priority Conflicts:  Let’s assume we follow the advice to clarify project objectives.  Everyone is on board.  And we’re sailing along until we hit the wall full force with a priority conflict.  Happens every day. 
    For example, in an on-time delivery project, a conflict arises between the Customer Service Department and the Planning Department related to expedited orders.  Customer Service is doing its best to satisfy customer needs and wants to change the schedule/ priority for the urgent order.  On the other hand, Planning wants to make sure the current orders are assured to get out the door on time and doesn’t have the bandwidth to review additional requests.  Both are focused on the objective of on-time delivery yet a conflict arises. 

    I’ve found the best way to overcome these types of obstacles is to re-clarify the objectives.  Is the company’s priority on oldest orders, customer feedback, or dollars shipped?  If it isn’t clear, get the two department heads together to discuss the topic.  Many times, talking through issues can lead to a solution.  If objectives are clear, perhaps you have a conflict in how to get to the objective.  Again, bring the appropriate resources together to debate and determine the best path forward.  You must set it up so that no one person succeeds if the team fails.  Ensure “win-win” is the philosophy.  Then, I guarantee the team will come to a conclusion. 

Overcoming obstacles is a part of our everyday routine.  Those who can jump over hurdles quicker and better than their competition will not only ensure project success but will also thrive in their careers.

Don’t forget to leave your comments below.