Agile Communications Plans

Project Communication PlansDolphins are easier to track than submarines. They surface more often and are usually within view of where you last saw them. Subs, on the other hand, can disappear for months or years at a time, and it is difficult to tell where they have gone.

What does this have to do with project communications? Has Mike finally gone mad?

These are valid questions, so let me explain. Many traditional project management deliverables have agile alternatives. For instance, a product backlog is somewhat analogous to a work breakdown structure. A release roadmap contains many of the elements of a Gantt chart. Yet we rarely see agile communications management plans. Why is this?

Why We Have Communication Management Plans
Projects can be time-consuming and costly, and tie-up valuable employees for long periods with no guarantee of the outcome initially hoped for. So, the responsible thing to do is to agree upfront on how everyone will be kept informed of the project’s progress, risks, issues, etc. This is where a good communications management plan comes in.

The project communications management plan outlines how all the various stakeholder groups will be kept informed of progress and issues. It outlines the frequency, format and distribution channels that will be used for communications. Given the high rates of change often experienced on agile projects, we might expect more emphasis on communications to keep everyone on the same page.

Show, Don’t Tell
Despite the lack of a formal communications management plan, agile approaches emphasize communication and information sharing extensively. In fact, transparency and sharing of information are baked into many of the agile practices. Let’s examine a few…

  • Demos – Having the team demonstrate increments of functionality at the end of every iteration shows what the project has achieved to date. The demonstrations are often accompanied by project spend summaries and updates on expected completion dates. Together they provide a good snapshot of progress and an opportunity for business representatives to provide feedback.

Frequent demos mean the project never disappears for long. Instead, the team regularly surfaces from work to show where they are with progress and discuss what should come next. It is this predictable cadence of show-and-tell sessions that creates the dolphins-versus-submarines comparison. 

Project Visibility

Agile projects frequently surface to show progress and discuss issues. They are like dolphins, frequently surfacing never too far from where they last submerged.

Predictive projects may have less to show the business and so have an increased reliance on communication management plans to keep everyone informed. After kickoff, a predictive project might be busy in analysis and design for long periods with only internal deliverables to show for their work. In these circumstances, they behave more like submarines, disappearing from view for long periods then emerging to present the solution. 

  • Kanban boards - The concept of “make work visible” is applied on agile projects to show what tasks are being worked on currently and the status of pending and completed items. Since knowledge work is often novel or unprecedented in the organization, it helps to have visual cues for it so people can point to it or examine its position on a Kanban board to determine its status in the development process.

Modern agile project management tools have a variety of Kanban board and backlog viewing tools so stakeholders can review progress and task status remotely. Since these tools also track when work changes state, they can also calculate and display metrics such as lead time, cycle time, WIP and throughput rates that help determine likely completion dates and costs.

  • Information radiators – A common theme between the various lean and agile approaches is to show and share information. XP has the practice “informative workspace,” Scrum encourages “transparency,” and Kanban development talks about making “process policies visible.” They promote graphing and sharing information—both good and bad—via large charts and graphs known as information radiators.

Information radiators can show any data the team wants to display. This could be a list of impediments or, as shown in the graph below, the cumulative threat scores for five well site-related risks over time:

Threat profile

These displays are used by the teams but also shared broadly with other stakeholders. Development team members, rather than a project manager, generally create these information radiators and, in doing so, broaden the set of stakeholders reporting on the project.

  • Daily stand-ups – Daily stand-ups are short (15 minute) meetings where team members share their progress, plans and raise any issues or impediments they have. It is an inter-team communication session rather than a reporting up of status to a scrum master or project manager. It facilitates collaboration, load-sharing and team planning. Other stakeholders may occasionally drop in to observe, but the goal is to help team members communicate among themselves.
  • Retrospectives – At the end of each iteration (typically every week or two), the team members meet to review how things are working and if any improvements can be made. This meeting is another scheduled event focused on information sharing.

The Agile Alternative to Communications Management Plans
By having multiple communication-focused events as part of the core agile practices, it removes some of the need for creating a separate communications management plan. Instead, people working in or with agile teams know there are events like demos, stand-ups and retros they can attend to learn about project performance. Likewise, there will also be Kanban boards and other information radiators available online to get project metrics.

Agile comms

Hybrid Realities
The dolphins-and-submarines analogy is a cute starting point to help explain some of the differences between predictive and agile communication styles. However, real-life projects are usually more complicated. Predictive projects that incorporate a proof-of-concept phase resurface and show progress. Phase-gate reviews may not demonstrate increments of a solution, but they are planned review points to assess progress, issues and funding.

Likewise, not everybody can attend a demo—nor wants to watch a recording of one to get a single question answered. The data on agile information radiators may not make it to all interested stakeholders, and pull systems for providing project data from websites will only work if people request (pull) the data. 

Mix and Match
It is normal and often necessary to schedule additional demos or review points within predictive projects. It may also be required to create communication plans for agile projects, especially those with distributed stakeholders. We should not assume that just because the information is available that it is being consumed or understood.

So, while agile projects frequently surface to show their progress and predictive projects can seem to disappear from our radars (sonars?) if we do not keep close tabs on them, we need to do more. We need to ask people how they want to hear about the project and ensure they know where to find the information. Check-in with them to make sure they were able to access and interpret it correctly.

We can use retrospectives and surveys in any project to learn about communication needs and wants. Given that the cost-of-change curve ramps up quickly, it is better to know about good news and bad news (in particular) as soon as possible. So, keep communicating and keep asking for feedback.

 

[Note: For more articles from Mike Griffiths, visit his blog at www.LeadingAnswers.com. Mike first wrote this article for ProjectManagement.com here.]


Estimating Agile Projects...Or Not

Estimate Features or FlowProject managers generally like plans and estimates so we can forecast when things should be done and how much they may cost. It helps manage client expectations and answer the type of questions they ask, such as "When will it be done?" and "How much will it cost?"

So, when project managers hear about ideas such as "let's stop estimating," it can trigger a knee-jerk reaction. It sounds lazy and avoiding the hard work of having to estimate. It can seem like people want to shirk their responsibility and accountability. First, those lazy agilists wanted to stop doing documentation; now they want to stop estimating too!

There has been a debate raging since 2012 about the use and value of estimates on agile projects. It has spawned the #NoEstimates hashtag, a website, a book and countless blog posts and conference presentations.

Like many radical ideas, when we dig into “no estimates” thinking, there are some good ideas, sound logic—and a whole heap of misunderstanding around it. This article sets out to unravel some of it.

My Exposure to NoEstimates
I should start by declaring which side of the debate I am on. Initially, I thought I was firmly on the side of estimates—but not the wasteful kind of detailed estimates that other people make when there is only limited information available. Instead, I aim to create reasonable predictions of the likely effort bounded by the uncertainty of the input data. Then communicate the estimates as a range to reflect the uncertainty and refine them as more information becomes available.

Then I discovered this is closely aligned with what the more reasonable NoEstimates advocates suggest doing anyway. It is just that they call them forecasts, not estimates. I can live with that; names are only labels that matter less than the meaning behind them. So then I felt conflicted.

NoEstimates Gets Started
In 2012, Woody Zuill wrote a blog post asking if getting better at estimating was the only way forward. He wondered if creating forecasts based on observations of completed work rates could be an alternative. The movement started, then more radical people got involved. They triggered more extreme counter-arguments against NoEstimates. However, let's de-escalate and look at some of the ideas that started the discussion. Then people can make up their minds based on their unique environment.

For software projects following an agile approach, the team is often asked to estimate the development effort for stories in the backlog. As the team starts work on these stories, they may discover some are more complex than initially anticipated and need splitting into multiple stories.  Others go as planned, and others get replaced by higher-priority changes and never get developed at all.

Throughput-Based Forecasts as an Alternative to Estimates
The effort and rigor of the estimation approach should be proportional to the quality of the input data. It would not be a good use of funds or people to apply time-consuming Monte Carlo analysis to a collection of guessed durations. So some NoEstimate enthusiasts classify over-analysis and more structure than the input data deserves as a form of waste.

We can argue even the act of estimating with imperfect input data is still valuable and gets the team discussing work that can uncover insights. Also, when spending other people's money, it is the responsible thing to do. However, let's follow the NoEstimates logic before making a judgment.

As an alternative to estimating all the stories for an upcoming iteration, NoEstimates supporters suggest a throughput-based forecasting approach. So, if the team completed 20 user stories last iteration, let's assume they will complete 20 this iteration also—and use the time that would have been spent on estimation work toward building new functionality.

It is easy to spot the flaw in this logic. What happens if these next 20 stories are much bigger or more complex than the 20 just completed? The answer is the team will not get through 20 of them, and the forecast will be wrong. However, before we dismiss this approach as unworkable, let's examine some of the things that can go wrong with traditional estimates on a software project.

We can spend a bunch of time estimating tasks, and they still turn out bigger than we expected or more complicated when we get into them. We can also spend time estimating work that gets deprioritized or swapped out with new work.

"The Same Poor Results, But with Much Less Effort"
Around 2006 at the agile conferences, I recall a presentation by Motorola on the effectiveness of using planning poker estimation compared to its previous, high-rigor approach. Motorola contained some CMMI Level 5 departments that conducted very detailed analysis and structured estimation sessions.

Part of being CMMI Level 5 is continuous improvement. So, in addition to rigorous estimation, teams investigated the root cause of any estimation errors to improve the process for the future. As an experiment, three teams substituted planning poker for their in-house estimation process. An additional three teams continued estimating as usual, producing detailed estimates with reviews, root cause analysis and ever more detailed estimating guidelines afterward.

The results showed that even the teams that followed the detailed in-house process were quite weak at estimation. Some items were overestimated, and many more were underestimated. Root cause analysis served to create ever longer checklists but did little to remove the variability of estimating work with human variation, uncertainty, complexity and risk.

The planning poker teams faired no better; they too were—at best—mediocre at estimating, often missing issues that created delays. The significant difference was that planning poker was much quicker than their existing estimation approach, and the team members enjoyed it much more. I still recall the presenter's summary that comparatively, planning poker provided "The same poor results, but with much less effort." Motorola was sold, and that department switched to planning poker.

Throughput-Based Forecasts
The NoEstimates camp takes this lesson one step further. They assert measuring throughput is as good (or more accurately, just as poor) a way of forecasting as estimating via hours or points—but crucially requires much less effort. When spending other people's money, should we focus on building valuable deliverables or creating estimates that, even with a costly rigorous process, are—at best—mediocre?

Of course, there are shades of grey. Some software is knowable and can be estimated reliably. Perhaps we should use estimation there. Some clients expect due diligence and evidence of planning rigor, and may want to know work is being estimated and not just started without due consideration.

I have worked with both types of forecasting. Each time throughput-based forecasting was used, the team had started forecasting with points. Then as the team became stable and trust was developed with the client, we found throughput metrics were reliable indicators of delivery dates and capacity.

Modern agile project management tools track when stories change state from, say, Ready for Development through Coding, Testing and Done. If this process is averaging five days per story and the product owner asks how long it would take to add some new high-priority feature, then—providing it is not too complex—probably about five days.

Likewise, if it took two months to complete the last 50 stories and there are 100 left in the backlog, then it will probably take four months to complete the project. No developers were interrupted to create those estimates.

Hybrid Options
Where I have used cycle time and throughput analysis to create forecasts, we have also tried to be smart about it. The team knows the process will only work if stories are sized appropriately. So they spend some time looking for anything that may be architecturally significant to investigate early via a spike. They also spend time splitting large stories—and sometimes tag stories with t-shirt sizes such as small, medium and large.

It can be argued that this is a form of estimation, and I would agree. But rapidly attributing small, medium or large to a story is quick and can be done by a senior developer not requiring (or gaining the wisdom) of the whole team.

Now we need to do some basic math with our forecasts. Small, medium and large should be relative, so a medium is two smalls, and a large is three smalls. Now the team can deliver 60 small stories or 30 medium stories or 20 large stories per iteration—or more likely, some combination such as five large, 10 medium and 35 small.

We have freed the team from estimating work (which even the best are not very good at), so it can focus on building products that hopefully it is better at. We can use throughput data that is provided free by our tracking software to forecast completion dates. Using these estimates multiplied by the team burn-rate (plus other costs), we can also generate cost estimates.

Downsides
I have only experienced throughput-driven forecasting working well with stable teams in high-trust environments. These teams had previously estimated their work and were very aware of their burn rate compared to budget and remaining work.

I fear teams not so aware of the need to deliver might work slower than if they had been through that experience first. Some environments and cultures find not estimating irresponsible. Also, some types of development can be estimated quite accurately, and so individual estimates could provide superior forecasts than tracking average throughput.

This article has described throughput-based alternatives to traditional task-based estimates. Some NoEstimates zealots deem that to be waste also, and believe teams should just work until done. However, I have yet to meet a sponsor not interested in evidence-based progress and completion forecasts.


Summary

Reducing or eliminating estimation can save considerable effort. When the last team I worked with made the switch, we saw the number of stories complete each week increase by 8% as more time was dedicated to development.

I teased the team members that this increase was because they were now making the stories smaller, and to determine if productivity had really gone up, could they please estimate the points of the recently complete stories so I could compare it to their old velocity figures. They saw the irony—but did not comply.

The NoEstimates debate could be recast as a discussion between bottom-up parametric estimating (team estimation via counting points) versus the heuristic estimation of throughput per iteration. Both approaches have their benefits and shortcomings. I realize this kind of simplification will anger members of both camps, but probably not the majority who are not vested.

Some organizations value the process and information brought about by bottom-up estimating. Others would rather redirect that effort toward development and use a different (even if inferior) heuristic estimation. Sponsors should always be asking, “How long will it take?” and “How much will it cost?” We have options to help answer those questions; ultimately, it should be the sponsoring group's decision about how it wants to see it happen.

[Note: For more articles from Mike Griffiths, visit his blog at www.LeadingAnswers.com. Mike first wrote this article for ProjectManagement.com here.]


Can We Still be Agile?

Can we still be agileHow does work from home impact our use of agile approaches? If co-location is no longer possible, can we still be agile?

Yes, of course we can, and in many ways, now we need to be more agile than ever as we try new approaches, learn and adapt how we work. However, let's address the co-location question and look at agile practices in remote work situations.

The Agile Manifesto and Agile Principles do not mention co-location. They do not say teams have to work together to be agile or effective. Instead, they say, "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation" and "Business people and developers must work together daily throughout the project."

Face-to-face (F2F) and daily business collaboration are certainly easier to arrange if people are co-located. However, most agile teams already had some remote workers before work-from-home instructions. The Digital.AI (formerly VersionOne) 2020 14th Annual State of Agile Survey reports 81% of respondents use agile approaches with remote team members (typically not the whole team, but a subset is remote).

Why F2F and Remote Alternatives
So, how do we do F2F remotely? The answer is with video. Instead of debating if video is F2F, let's look at where the F2F agile recommendation came from in the first place. Alistair Cockburn, an Agile Manifesto signatory, developed a popular graph to show various forms and levels of communication effectiveness. Later, Scott Ambler expanded the graph to show types of modeling and added video conversations.

The goal of the chart was to show how interactive, F2F discussions are more efficient in terms of data transfer per minute than traditional paper documentation and allow for questions and answers to clarify understanding. They also convey emotion through tone of voice and body language, so are richer forms of communication.  Here are the two graphs merged with F2F and video marked as points 1) and 2)…

Agile Communications

We can see both F2F 1) and Video conversation 2) are in the top right quadrant of the graph indicating high effectiveness and high richness (emotional temperature). Video is slightly lower on the curve than F2F conversation, but still significantly higher than working via email or documents. The highest form is working together at a whiteboard, where we also bring the benefits of visual collaboration.

I suspect there was not a lot of data behind the exact positioning of these communication forms. Instead, it is a visual to help discuss a continuum of information transfer formats. One conclusion is that if F2F is not possible, then video conferencing is our next best option, and it still allows us to get a feel for people's temperament and emotion about a topic. 

Other Agile Approaches
Rounding out our review of agile recommendations, the Scrum Guide does not mandate or even recommend co-location. It talks about teams working together to build a product. However, groups can work together on a product remotely. For instance, Jim could build the website while Rosa develops content. They are both working together on the product, just not physically together.

Extreme Programming (XP) includes the practice “Sit together” as one of its primary practices and notes “The more face time you have, the more humane and productive the project.” Remote teams fail to meet this practice recommendation and video face time is not the same as in-person face time. However, XP co-creator Kent Beck explains “sit together” is a goal and is not mandatory.

We should also remember when the agile principles were developed in 2001, video conferencing was not as straightforward or familiar as it is today. It was not until 2003 that Skype and other applications provided widely used and low-cost options for getting some face time.

Team Types
The image below shows different team composition types. First, Type-1 teams are fully collocated. According to agile surveys, these are the minority. The majority of agile teams are Type-2, which have a core of co-located team members, but also some remote team members. Finally, Type-3 teams are all remote, with everyone contributing from their own workplace.

Remote Team Types

During the COVID-19 response, many organizations have gone from Type-1 or Type-2 quickly to Type-3 due to work-from-home mandates. This change has brought about technology and work challenges, but also highlighted opportunities for the future.

A common problem with Type-2 teams is that there can be a division or communications gap between core co-located and remote team members. Some information may, unconsciously, not get shared with remote team members. Going all remote, Type-3, is a great leveler. Now everyone is in the same boat, and the need to communicate broadly is highlighted and universal.

Lessons from Experienced All-Remote Organizations
Many organizations have been successfully using Type-3, all-remote structures, for years. They deliberately chose this format and believe it offers many advantages.

Organizations like Automattic who build products including WordPress and Tumblr, employ over 1,100 people in 75 countries using an all-remote strategy. GitLab, makers of the code repository and development tools, has 1,295 team members spread across 67 countries using their all-remote work practices.

Automattic uses agile approaches to build its products. It created its own distributed team project management product called P2, that it uses to organize, communicate and build community. It also embodies some key aspirational goals in the Automattic Creed. These include:

  • Never stop learning
  • Do not just work on things assigned
  • There is no such thing as the status quo
  • Never pass up an opportunity to help a colleague
  • Communicate as much as possible, because it’s the oxygen of a distributed company

The reference to oxygen in the communication concept is deliberate because too much oxygen can be fatal as well. As a group scales, it’s important to invest time from an editorial mindset making sure that the right information isn’t just published, but it’s heard and understood by those who need to.

GitLab also builds agile tools and uses agile approaches. It has a vast resource library about working remotely that any organization could learn a great deal from. Similar to the Agile Manifesto, Gitlab has its own published values and manifesto.

GitLab's six values are:

Collaboration
Results
Efficiency
Diversity
Inclusion & Belonging, Iteration
Transparency

…that together spell the “CREDIT” given each other by assuming good intent. Their remote manifesto reads:

  1. Hiring and working from all over the world instead of from a central location
  2. Flexible working hours over set working hours
  3. Writing down and recording knowledge over verbal explanations
  4. Written down processes over on-the-job training
  5. Public sharing of information over need-to-know access
  6. Opening up every document for editing by anyone over top-down control of documents
  7. Asynchronous communication over synchronous communication
  8. The results of work over the hours put in
  9. Formal communication channels over informal communication channels

Items 3, 4 and 9 favor written communications over verbal. In a remote setting, this is preferable so people can consume it wherever and whenever they please. Yet it is at odds with the Agile Manifesto that favors F2F communications with its immediate feedback and richer bandwidth. However, these remote organizations have an ace up the sleeve that likely more than makes up for any communication penalties.

People over Process
Accessing the best talent is the saving grace for remote teams. There have been many studies and speculation about the productivity differences between average and best-in-class workers. Some reports claim 2X, 3X and even 5X differences in software developers, but I suspect the data is shaky at best. Yet some classes of problems can either be solved or not. Working longer for someone unable to solve a problem is not going to help.

The argument for remote agile teams is that the efficiency penalty from sliding down the Communications Effectiveness graph from F2F to videoconference or documentation is more than made up for by having the best possible people. Also, because “work from wherever and whenever you like” offers great flexibility, the best talent is attracted and retained.

Remote Work and Agile Values
There are many parallels between all-remote work structures and agile principles.

  • Autonomy - For remote teams to function best, organizations adopt a results-oriented view of work. They trust their staff to work independently, collaborating and communicating as required to create the outcomes desired. They do not try to micro-manage or schedule tasks. Instead, they allow people to organize their work and operate with autonomy. This mindset closely mirrors “empowered teams” from agile approaches.
  • Transparency – People are encouraged and expected to communicate widely and frequently. Automattic’s “Communicate as much as possible” and GitHub’s “Formal communication channels over informal communication channels” emphasize communication. These ideas map to the agile and Kanban concepts about making work visible and Scrum’s Transparency pillar.
  • Challenge the Status Quo – People are expected to be curious and always looking for new markets and improvements. These concepts align well with the inspect and adapt ideas of retrospectives and continuous improvement in the agile mindset.
  • Iterate – Working iteratively is one of Gitlab’s core values and a central theme of agile approaches.
  • Valuing individuals – Recruiting globally and providing flexible work options, even if that means more written documentation, is an excellent example of living the agile value “Individuals and interactions over processes and tools.”

Summary
Remote teams can be agile. They do experience some disadvantages by not working together. All-remote, Type-3 organizations admit that onboarding can be a challenge, and communications take longer. However, access to the best talent, providing flexibility and autonomy offset these drawbacks.

When people value agile principles, they usually find a way to make it work no matter the circumstances. However, being agile is not the point; building an engaged, energetic workforce who support each other and create worthwhile outcomes is the real goal and measure of success. 

Useful Remote Work Resources

  1. GitLab “GitLab’s Guide to All-Remote”
  2. Automattic “On Working Remotely” 
  3. Stefan Walpers’ “Remote Agile Guide

 

[Note: For more articles from Mike Griffiths, visit his blog at www.LeadingAnswers.com. Mike first wrote this article for ProjectManagement.com here]

 


Reset, Refocus: 2 Concepts and 8 Tips for Making Progress During the Pandemic

Ideas to tryIt is a dilemma. We need to move forward. Not just to make progress on projects, but also to give people something else to focus on beyond the tragedy and fear filling the news.

At the same time, we need to be sensitive to how people have been impacted. We need to demonstrate support and empathy. We need to be available to listen and help wherever we can. We need to step up and be professionals.

Context
More than ever, context is king. How to respond and lead in your environment will depend on how your project and stakeholders have been impacted. There is no universal best response. All I can do is offer some tips for consideration. You can then decide if they apply—and how to implement them for your environment.

Concept 1: Demonstrate Empathy – Cut people some slack. Be there for them, listen and empathize with them. Maybe they have lost family members or are worried about elderly and at-risk family members. Perhaps their work-from-home environment is challenging with children needing help, poor internet service, and less-than-ideal work set-up.

So, provide some emotional support, and demonstrate empathy and active listening. Now is not the time to be a stickler on schedule or tasks. Now is the time to show compassion and build a stronger foundation of understanding and trust for future performance.

Concept 2: Take an economic view of decision-making – Social distancing and work-from-home policies have likely blown away your original project plans. We now need to determine what can be done and what should be done first. There will be some tasks that can still proceed, and some opportunity or threat responses than can be pursued…but how do we decide the sequence?

Taking an economic view of decision-making helps with sorting through the options. After reviewing what is possible, ask “Where is the next best dollar spent?” We can then start to prioritize work and match it to availability. The goal is to deliver as much value and make as much progress toward the desired business outcomes as possible.

So, if Activity A has a projected ROI of $15K, Activity B will save $18K in maintenance and Activity C has a 50% chance of returning $32K, prioritize them B, C, A. Share these ideas with the team; we need everyone to adapt and prioritize their time toward the high-value activities.

8 Tips for Reprioritizing

1. Check-in with your sponsors. Explain how you plan to continue working toward the intended business outcomes despite the changes. If appropriate, ask them if there are any new, higher-priority initiatives the team can be helping with. You do not want to be the project still making door handles when the rest of the organization has switched from building cars to ventilators.

2. Scan your WBS or backlog. Can any items of work be pulled forward and worked on remotely? Can some portions of future work be done now and remotely? Usually, we avoid partially completed work as it raises WIP, but these are extraordinary times. If it will need doing and can be done now, it might be the next-best-dollar-spent thing to do.

3. Revisit the vision and business case. Look for untapped opportunities and benefits. Perhaps there are objectives that were not immediately scheduled because they were a lower priority or required skills in short supply back then. Maybe we can find useful activities or different paths to the same goals that might now be viable?

4. Review the risks. Review the risk log to determine if any opportunities can be exploited, shared or enhanced at this time. Do the same with the threats and ask if any could be avoided, reduced or transferred by action that could be done remotely.

5. Communicate to your stakeholders what work can go ahead and what is not happening right now. Keep your communications short; stakeholders likely have plenty of extra work of their own that they are trying to get through. However, provide links to where they can find more information should they want it. So, short announcements and emails, with “more details” links so people can pull more information if necessary.

6. Put it to the team. Do not try and solve everything yourself. Your team members likely have some great ideas, too. Engaging them in finding ways to move forward recognizes their expertise and also demonstrates the desired behavior of asking for input and help.

Ask them what we can be working on. What are the highest value activities that they could be doing right now? Invite them to review the WBS/backlog and risk lists also. Ask about useful maintenance work and new product ideas. How can we use some extra thinking time to emerge stronger?

7. Contact suppliers, vendors and partners. Ask them how they are coping. Maybe there are some easy things we could do to help them. Or, an early heads-up on insolvency is better than learning about it when we need them for something.

Also, ask them for ideas. They likely know aspects of your project very well. Perhaps they can identify valuable work that could be done early. Check their suggestions for validity and self-interest bias. Ordering that flux capacitor jetpack might help them, but does it really help your project and organization right now?

8. Upskill. Use work-from-home time to gain new skills and undertake training. As a minimum, make sure everyone completes their compliance training, which includes working through all the mandatory health, safety and respectful workplace modules. That way, when people return to work, they will not be taking time out to complete these activities later. Then encourage professional development. What new skills, roles or tools would be helpful to learn?

These are challenging times. They are also opportunities to demonstrate desired behaviors. Being compassionate, helpful and understanding in times of stress and hardship are critical. So too is keeping a cool head, being flexible to change and open to help.

The measure of intelligence is the ability to change.”
― Albert Einstein

Thanks for reading, and please share other ideas for us to consider.

[Note: For more articles from Mike Griffiths, visit his blog at www.LeadingAnswers.com. Mike first wrote this article for ProjectManagement.com here]


Problem Solving: Using Visualization

Some people say we cannot manage what we cannot measure. I say we cannot solve what we cannot see, or at least visualize somehow.

Projects are problem-solving exercises. The entire project is one big problem. We might be building a new product; that's a problem to solve. Or we might be trying to create something well understood but within a challenging amount of time, to a tight budget, and demanding specification. Or we could be moving our organization forward through a change initiative. These are familiar project environments that are puzzles or problems to solve.

Visual Problem Solving for Project Managers Mike Griffiths 1

Then within this large problem environments, we have hundreds of everyday challenges to answer, too. "How are we going to manage without the installer today?" or "The pilot group has requested 400 changes, now what do we do?"

Once we see projects as puzzles with more puzzles within them, we realize the importance of practical problem-solving.

Visual Problem Solving for Project Managers Mike Griffiths 2

Rarely do project managers have all the answers or the best answers. So we need to share the problem and collaborate on developing a solution. This is why being able to visualize problems is so important.

Visualizing a problem helps us understand it ourselves and then gain consensus with others on it. It also allows us to determine if we are all seeing it in the same way. Drawing something also lays it out spatially, allowing people to see relations, sequence and connections, or whatever we want to depict.

Here is the structure of this article as a list of bullet points:

  • Introduction
  • Why visualizing is helpful
  • An example from a real project
  • Ways in which we can visualize
  • Wrap up and recommendations

Here is the same information as an image:

Visual Problem Solving for Project Managers Mike Griffiths 3

Research into visual thinking by David Hyerle, creator of Thinking Maps methodology, reports that 90% of the information entering the brain is visual.

Visual Problem Solving for Project Managers Mike Griffiths 4

Also, 40% of all nerve fibers connected to the brain are for the retina, and a full 20% of the entire cerebral cortex is for vision, so let's use it.

Creating a visual helps us to tackle a problem in steps. Having a spatial reference allows us to park some elements until later. We can say: "Yes we still need to solve the atmosphere re-entry problem, that's shown over here; but right now we are tackling the launch problem." Separating components in this way allows us to focus on one element at a time.

A Real-Life Example

I once took over a struggling project that was using a complex combination of proprietary hardware, software and vendor products. It mixed in-house developed software and cloud-based services—and was difficult for me to comprehend. I went through all the documentation but struggled to see how the elements worked together. To get up to speed, I knew I had to draw it all out to understand it.

I met with stakeholders, asked about how their part worked and drew it out with them. They provided lots of corrections and additions. I then showed the whole thing to the team, and they found even more omissions, which I filled in. I felt like they were humoring me, helping me get my little project manager brain around the complex system they had spent years developing. However, then they announced they had never seen it all mapped out in a single (very large) image before.

We ended up using the diagram repeatedly going forward within the team to discuss issues and to onboard new members. I also used simplified versions and zoomed-in portions for explaining elements of the project to the steering committee.

If you are missing a big picture view of your domain, you probably need to make one. It is a great way to surface misunderstandings and gain alignment on thinking.

Luckily, we do not need to be artists—or even competent at drawing. Stick figures, boxes and lines are all we need. Yes, it is pleasing to have a well-drawn vision of strategy poster, but for most instances, basic drawings are just fine. If we need a professional looking image, there are always graphic artists we can engage. Here is how I show some of the roles of a PM:

Visual Problem Solving for Project Managers Mike Griffiths 5

The images are not well-formed or accurate, but convey more meaning than words would alone.

Books such as Visual Collaboration walk readers through the drawing process. They show how to create simple but powerful graphics to help direct meetings, ask powerful questions, and create clear strategies.

Using images sounds like a luxury, right? "I do not have time for that!" Maybe, but are your messages getting through?

Using images helps people retain information. Most people only remember 10% of what they heard three days ago. Add an image to the message, and this figure jumps to 65%.

Visual Problem Solving for Project Managers Mike Griffiths 6

So, if we are going to the trouble of interrupting people from their work, we owe it to everyone to make it worth their time. Better to spend the extra time and create a visual than disrupt them six times with the same message to achieve similar retention.

In a team setting, we can use images when capturing opportunities and threats. The sailboat exercise allows people to record and place threats, opportunities and issues on an image with sticky notes:

Visual Problem Solving for Project Managers Mike Griffiths 7

We use anchors for threats that could impede progress and depict opportunities as the wind in the sails to propel us forward. Cheesy? Yes, but providing spatial separation and getting people up on their feet, contributing and generating an image they are more likely to remember is worth the cheesiness.

Finally, hand-drawn and group-generated images are more personal, more human and more uniting. They are ours; we created them, and we are more invested in achieving their goals than outcomes shown with generic Gantt charts or schedules. Involvement increases commitment, and human is more approachable than automated.

Visual Problem Solving for Project Managers Mike Griffiths 8

Final Recommendations
Here are some tips for problem-solving with visuals:

  • Find ways to visualize the overall project problem; this allows people to see the big picture.
  • Break down the interim puzzle pieces to show relationships, sequence and solution alternatives. Use these visuals to encourage collaboration and build support for group-generated solutions.
  • Don't be shy about your amateur art. Your chicken-scratch stick people demonstrate a vulnerability that increases empathy and encourages others to have a go. Starting with a fancy image may inhibit people from contributing as they do not want to spoil your picture.

While rough-and-ready visuals are suitable for working sessions, there are times when you will want to invest more time and effort. Externally facing artifacts such as plans, roadmaps and product visions will benefit from the best images you can create.

I sometimes create project milestone posters for stakeholders to recognize their contributions and the obstacles we have overcome together. These work well for thank-you cards and foam-board plaques. Here are a couple of examples:

Visual Problem Solving for Project Managers Mike Griffiths 9


Visual Problem Solving for Project Managers Mike Griffiths 10

I like to embed insider jokes and references to some of the issues we faced.

Projects are adventurous journeys we share with our stakeholders. Just as we would use maps and take photos on physical trips, we can do the same for our project endeavors to recognize and remember the venture. So be brave and get visual!

[Note: For more articles from Mike Griffiths, visit his blog at www.LeadingAnswers.com. Mike first wrote this article for ProjectManagement.com here.]

Copyright © 2020 Mike Griffiths, Leading Answers Inc.

 

 


WBS and Product Backlog: Siblings or Distant Cousins?

WBSandPBIt’s easy to believe that work breakdown structures (WBS) have been around since the pyramids were built in Egypt, and that product backlogs are new inventions by youngsters in too much of a hurry to plan correctly. However, like most things, the truth is more complicated.

In 1957, the Program Evaluation and Review Technique (PERT) approach was created by the United States Department of Defense (DoD) and described organizing tasks into product-oriented categories. However, they did not use the term “work breakdown structure” or WBS until 1962 when DoD, NASA and the aerospace industry published a document about PERT that described the WBS approach.

Meanwhile, in 1960, Tom Gilb described his Evolutionary Value Delivery approach (or Evo for short) that is widely accepted to be a forerunner of agile approaches. Evo contains principles such as:

  • E1: Decompose by performance results and stakeholders –  Break down the work into small (weekly) value delivery steps
  • E2: Do high-risk steps early – Prioritize the work based on risk
  • E3: Focus on improving your most valuable objectives first – Also prioritize the work based on business value

These ideas became the concepts embodied in backlogs by today’s agile approaches and frameworks.

So, we can trace each approach back to around the same time and also be confident these ideas were firmly established long before that. Building the pyramids and Roman cities required multiple levels of planning, work decomposition and task coordination. There is little point in arguing whether WBSs or backlogs came first since it was clearly lots of other things.

These days, the PMI Practice Standard for Work Breakdown Structures defines a WBS as “…a hierarchical decomposition of the total scope of work to be carried out by the project team to accomplish the project objectives and create the desired deliverables.” The Scrum Guide defines a product backlog as “an ordered list of everything that is known to be needed in the product.

Are they really so different? They both help with forming an agreement on scope. Yet, due to how they are often used, they are viewed as quite different by many people…a viewpoint I would like to change.

WBS and Backlog

WBS and Backlog Similarities and Differences
Work breakdown structures are often defined upfront and supported with a WBS dictionary. They can be used to form statements of work and contracts. If these deliverables are useful for your projects, then great, create them. However, understand we could create the same deliverables from a product backlog also.

Yet, on agile projects, we typically do not because these environments tend to be more dynamic so these deliverables would soon be out of date. Instead, we create iteration plans, release roadmaps and work from the top of the backlog while the product owner manages the backlog with evolving priorities and change requests. These deliverables are easier to update as changes occur. The differences we see in action stem more from the characteristics of the work environment than the WBS or backlog tool in use. Both help us define and discuss scope.

Visual Benefits
Both are visual and allow us to point at items as we talk about them. This is critically important. Visual depictions of work allow us to collaborate more effectively. When two people face a task board or WBS diagram, they can collaborate with less contention. Visualizations help us build shared understandings and avoid confusions such as having two similar items being considered the same thing or assuming one solution fits two scenarios when it does not.

Depicting scope visually also allows us to shade and color items to indicate type, ownership, risk and completion status.  Visualizing work is a major component of lean thinking. When we visualize something, we also process information using more of our brain—and much more quickly compared to reading and interpreting written information. This is one reason we have road signs with images and not descriptions to read. It is the difference between decoding and understanding meaning in 150 microseconds (roads signs) versus 6,000 microseconds for reading:

Signpost

Product Backlogs as a form of WBS
The third edition of the Practice Standard for Work Breakdown Structures talks about backlogs as a form of WBS. Many people think only tree structures of boxes and lines are work breakdown structures, but they can actually take on many forms including tabular backlogs or even mind maps.

I can imagine some purists shouting “No, that’s not a WBS!” as I type this, but go check it out for yourself if you do not believe me. The Practice Standard for Work Breakdown Structures WBS is a free download for PMI members. 

I participated as a reviewer for the standard and was pleased to see its coverage of agile scope decomposition using epics, features, user stories and tasks as candidate WBS elements. One thing that puzzled me that I am hoping a reader of this article can help me with is the inclusion of sprints or iterations as potential WBS elements.

My confusion stems from the logical definition of work in section 2.1 that says “… work refers to outputs, work products, or deliverables that are the results of effort, not the effort itself.” – that makes sense. Then in section 2.3.1.1 on WBS rules it says “WBS elements do not account for time or sequence.” Again, that seems reasonable.

However, the examples for agile projects include a WBS with level 2 items showing “Iteration 1,” “Iteration 2,” etc. containing work. This seems to violate the deliverables versus effort definition of “work and no-time” rule. We would not have a WBS element called “September,” so why call out some arbitrary time box? Iterations are just time constructs, and you might choose to use them or work without them as a continuous pull of features from the backlog.

Likely I am interpreting the work, deliverables and no-time rules too literally and, like debating which approach came first,  it probably does not matter. If having iterations shown helps you share your plans and have meaningful conversations about scope, then go for it. I would imagine it would result in having to refactor the WBS frequently as stories get shifted between iterations as priorities change and throughput varies, but maybe not.

The more important idea is that we visualize and discuss project scope with a wide variety of stakeholders to surface and correct misunderstandings. The good news is that product backlogs are a legitimate form of WBS and more of a sibling than a distant cousin. A couple of great quotes from the WBS Practice Standard reiterates the value and applies equally well to backlogs and release roadmaps:

The WBS provides the foundation for a visual representation of the scope of work…Research demonstrates that communication is one of the project management disciplines with the highest impact on project success. The WBS serves as a critical project communication mechanism that helps convey the scope of the project through its graphical depiction.

So let’s get graphical and keep communicating.

 

[Note: This article first appeared on ProjectManagement.com here. For more articles from Mike Griffiths check his blog www.LeadingAnswers.com]


5 Major Changes Coming to the PMP Exam

5 ChangesSome fundamental changes are coming to the PMP® exam. Currently slated for January 2021, the content and composition of the exam will be completely revamped. As described in the new PMP Exam Content Outline, PMI commissioned a research study into trends in the project management profession. This study, called the Global Practice Analysis, investigated which job tasks and approaches people frequently use.

The job task analysis identified the knowledge and skills required to function as a project management practitioner. Now the PMP is changing to better reflect these practices; here are some of the major changes:  

New Focus1. New focus– Switching from the previous domains (initiating, planning, executing, etc.), the new exam will be based on three new domains: people, process and business environment. These new domains align more closely with the PMI Talent Triangle®sections of leadership, technical project management, and business and strategic work.

Since project management occurs in a variety of industries, the business environment domain only tests universal concepts and does not get into any specifics around project types. The split of questions between these domains is:

  • People: 42%
  • Process: 50%
  • Business Environment: 8%

New Content2. New content– The job task analysis revealed that many project managers are using agile approaches, or some agile concepts in hybrid life cycles. To reflect this, the new exam covers the complete value delivery spectrum including predictive, hybrid and agile approaches.

The inclusion of agile concepts and increased emphasis on the people aspects of projects represent a big shift. Concepts like servant leadership, conflict resolution and retrospectives were previously the domain of the PMI-ACP® exam, but will now be featured more frequently on the PMP exam (although not in so much depth or frequency).

New Question Types3. New question types– A change announced by PMI at the recent PMI Global Conference in Philadelphia was the introduction of some new question types. PMI will be introducing question types that depart from the tradition multiple-choice format of four options and one correct answer.

The new format questions include drag-and-drop and clicking on a graphic region. These new question types allow questions such as asking the test taker to select the graph/chart that best fits a described scenario, or identify what part of an image applies to a described situation.

Crossword and coloring-in based questions will be added later (just kidding). Personally, I applaud the incorporation of visual questions; a large component of effective communication involves interpreting and creating graphs and charts, so any way to assess this capability is welcome.

Move Away from PMBOK4. Moving away from the PMBOK® Guide – The PMP exam is not a test of the PMBOK Guide.

This concept is so fundamental—yet so universally misunderstood—that I feel the need to repeat it: The PMP exam is not a test about or on the PMBOK Guide. This misunderstanding may have arisen because the domains in the old PMP Exam Content Outline matched the process groups in the PMBOK Guide. This was a logical (but flawed) assumption.

When question writers develop questions, they must reference at least two source documents for each question. This is to make sure the question is based on agreed-to sources and not just their belief or recommendation. Previously, the PMBOK Guide was frequently used as one of the sources, but it was always accompanied by at least one non-PMBOK source.

Since the Global Practice Analysis and job task analysis identified more people-based skills and agile approaches, then increasingly, the sources referenced will not include the PMBOK Guide. By structuring the PMP Exam Content Outline around people, process and business domains, PMI is further signaling the departure from PMBOK-focused topics. The list of new source materials is available here.

The takeaway for PMP aspirants is to base their studies on understanding and applying the concepts described in the domains, tasks, and enablers listed in the exam content outline.

Education Evolution5. Education evolution– These radical changes were planned to be implemented in December 2019. However, perhaps in part to questions from the training community, the changes have now been deferred until July 2020.

No doubt it will be a big change for Registered Education Providers (REPs) as they update their materials. Many PMP preparation courses followed the knowledge areas and domains of the old exam content outline. Now, with more of a focus on people and the decision to embrace the entire value delivery spectrum, training materials should be changed to better reflect the new exam content outline. This will take time but will result in a more practical exam.

Conclusion
I welcome the change to make the exam more realistic and better aligned with how projects operate. The increased emphasis on the people aspects of projects more closely reflects where project managers spend the bulk of their time and attention. While the process groups and knowledge areas were useful buckets for organizing content, they did not really map how the project management activities integrate across multiple domains simultaneously.

There will be an adjustment period as training companies adjust their materials. However, the end result will be an exam that better matches day-to-day work—which ultimately is where the exam should be moving to so that it’s a relevant assessment of project management activities.

[This post first appeared without the list of source materials on projectmanagement.com here]


Innovation: Running Experiments and Learning

Experiment DesignIn my last article on Incubating Innovation, we explored the culture and mindset of accountable experimentation. This article focuses on actionable tools and approaches.

Within agile frameworks, the team retrospective is the primary workshop for planning and evaluating experiments. Yet most team retrospectives I see are broken.

Teams spend too much time recording viewpoints and information—but not enough time reviewing or planning experiments. It is common to see the majority of the time spent gathering what went well, what did not go well, and appreciations. Yet where’s the focus on experiments, the learning process and trials for the next iteration?

To make things worse, some teams do not take the retrospective seriously. Maybe after the potential stress of the sprint review, the largely internal retrospective is a relief. A chance to chill out, maybe share some food, and pat each other on the back. However, innovation and learning take conscious effort, forward planning and accountability.

As I work with organizations, I often sit in on retrospectives. Of all the regular workshops/ceremonies, these sessions are typically the least prepared for and worst executed. I often see lazy retrospectives where a basic lessons-learned format is used, but timings are not managed and the recommendations for the next sprint get skimped as they run out of time.

The pie chart below shows a typical planned allocation of time—and the reality of how time is actually spent:

R1

In these lazy retrospectives, people are slow to start, spend longer on recording what went well than what could be improved, and then try to cram the recommendations for experiments (the most important part) into the last few minutes. As a result, experimentation suffers. Few experiments are scheduled for the next sprint, and those that are run are not evaluated properly.

This is not how agile retrospectives are supposed to operate. An excellent guide to running effective retrospectives is Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen. In it they describe a five-step process:

  1. Set the stage – Help people focus on the task at hand; check that people are ready and willing to contribute. Outline and gain consensus on the process we will use. Techniques we can use include: check-in, working agreements, focus-on/focus-off (see the book for full descriptions of these techniques).
  2. Gather data – Create a shared view of what happened during the sprint/iteration. When completed, we should have a common understanding of the observations and facts. Team activities we can use include: timeline, mad-sad-glad, team radar.
  3. Generate insights – This focuses on understanding the implications of our findings and discussions. We need to see the impacts of the problems we are faced with before trying to solve them. Techniques we can use include: five whys, fishbone analysis, dot voting.
  4. Decide what to do – Now we move from thinking about the iteration that just ended to what we should try next to improve things. We identify the highest-priority action items, create plans for experiments and set measurable goals to achieve the desired results. Techniques we can use include: SMART goals, circle of questions, short subjects.
  5. Close the retrospective – Here we reflect on the retrospective process and express our appreciations. We may summarize what we have decided to keep or change and what we are thankful for. Team-based activities we can use include: plus/delta, return of time invested (ROTI), appreciations.

This is a more useful format. However, despite people having access to good retrospective advice, poor implementations are still common. Teams continue to attend late, start slowly and run out of time or rush the agreement on what experiments to run.

R2

The recurring theme is poor experimentation design and restricted learning. Gunther Verheyen summarized the problem nicely in his recent post entitled “Inspection Without Adaptation Is Pointless.” Gathering data and deciding what to do is pointless if it is not acted upon. We are doing most of the preparation work but not getting any of the benefits.

Experiment Design to the Rescue
Fortunately, there are some good models we can use. We need to manage time and effort more effectively and use retrospectives to plan and evaluate more experiments. We should spend only 50% of the available time on gathering information and the remainder reviewing the results of past experiments, making wins part of our process, designing new experiments and learning from inevitable failures.

We can help the time management problem by assigning work to be done in advance. People should be thinking about issues and potential solutions independently. There are benefits of group discussion and consensus gathering on agreed experiment design, but observation and idea generation is best done individually.

The New Yorker magazine [3] describes numerous studies that show how brainstorming groups think of fewer, lower-quality ideas than the same number of people who work alone and later pool their ideas. There have been numerous reports on the downsides of brainstorming ideas as a group. Groupthink and the halo effect stifle idea generation. So, ask for people to come with ideas, then use the group setting to vet and vote for them.

Visualizing the ideas and experiments is an effective way to bring collective attention to them. Trent Hone and Andrew Jarding developed the “Ideas and Experiments board” pictured below. It shows the progression of ideas through experiments and their success or abandonment:

Experiment Board

Ideas and Experiments Board (Image Credit: Trent Hone and Andrew Jarding, MindSettlers)

As discussed in the last article, by design, 50% of our experiments should fail since we are trying to maximize our learning, not validate things we already know. So I would expect to see an equal number of abandoned experiments as successful ones.

However, this format (or a slightly modified version that represents an experiments Kanban board) is a useful tool to bring the focus for retrospectives to the experiments being run and considered. With some pre-work on idea generation and an increased focus on experiments, we can structure more effective retrospectives.

R3

This retrospective format saves some time by assigning idea generation as pre-work; this also helps avoid the groupthink pitfalls. It furthermore places emphasis on the experiments—the inputs for learning and innovation.

I have experienced pushback from teams about the goal of 50% experiment failure. People understand it optimizes learning—but say it sets people up for too much failure. I understand the sentiment but counter with two perspectives.

First, these are experiments; they should be dispassionate explorations, not evaluations of the people undertaking the work. We need to be professional and try to overcome habits of internalizing results. I know this is easier said than done, so also offer a second reason: We need to kill bad ideas early to save time and money for better ones.

In the article “The Hard Truth About Innovative Cultures,” Gary Pisano describes how killing bad ideas is critical. He profiles Flagship Pioneering, a Massachusetts-based R&D company. It uses a disciplined exploration approach to run small experiments minimizing expenditure. Instead of running experiments to validate ideas, it designs “killer experiments” to maximize the probability of exposing an idea’s flaws. The goal is to learn what went wrong early and move in a more promising direction.

Other useful ideas from the paper include:

  • Tolerance for failure, but no tolerance for incompetence – Hire the best people you can. Explain the goals clearly and let go of those that do not perform.
  • Psychologically safe, but brutally candid – Encourage frank but respectful two-way dialog. It may feel uncomfortable, but it can prevent issues or concerns from going unreported.
  • Collaboration—but with individual accountability – Encourage discussions, but avoid groupthink and hold people accountable for decisions and outcomes.

These are all great concepts and align with the frustrations I experience when I see teams not taking retrospectives seriously—or following through on conducting experiments. I realized I needed a better model for discussing the problem. Fortunately, I found the field of collaborative problem solving (CPS).

CPS is the study of how we work together in groups to solve new problems, innovate and build products. The innovation process and retrospective workshop fall squarely within its scope. CPS skills are quite separate from individual task-focused skills, meaning people can be great at working individually but poor at working together.

A good introduction to CPS frameworks can be found in the article “Advancing the Science of Collaborative Problem Solving.” One model they feature is the “PISA 2015 Collaborative Problem-Solving Assessment.” Unfortunately, like many academic models, the degree of difficulty goes downward, which may make sense as you read down through more advanced stages. However, I think graphically, so I have redrawn the model to show degrees of completeness and difficulty radiating up and out from a 0,0 origin, as shown below:

PISA 1

Along the X-axis, we see three categories of collaborative problem-solving competencies. These are:

  1. Establishing a shared understanding
  2. Taking action to solve the problem
  3. Establishing and maintaining team organization

Up the Y-axis, we have four categories of problem-solving:

  1. Understanding the problem
  2. Representing the problem
  3. Planning and executing
  4. Monitoring and reflecting

Within the body of the model, each square is labeled with the column number and row letter, and describes the tasks that occur in that space.

The model provides a diagnostic tool for identifying broken and lazy retrospectives. The poor engagement and weak follow-through I see in many Scrum teams is characterized by an incomplete execution of column 1 and only half-completion of columns 2 and 3 (as shown by the red outline below):

PISA 2

Teams are not spending time in “(D1) – Monitor and repairing the shared understanding,” nor are they getting to the “(C2) Enacting plans,” (D2), (D3) and (C3) areas to follow through on plans and hold each other accountable for actions and results.

What we want is a complete execution of all the collaborative problem-solving competencies; only then is the framework complete (along with the feedback mechanisms to keep things in check and moving in the right direction):

PISA 3

Summary
Innovation involves combining the right mindset and philosophy with tools and practical steps to ensure its execution. Motivation and attitude are paramount; people have got to want to do this work, enjoy it and create a pull demand for the tools and process that enable it. Trying to foster innovation with demotivated teams is like trying to push a rope.

When motivated and happy people create a strong pull demand for innovation, we need to be ready with the right tools to support the process and keep the momentum going. This includes designing experiments to maximize learning and killing bad ideas quickly—all while demanding competence, accountability and candor.

It is not easy to master the combination of soft skills and techniques required for successful improvement and innovation. However, organizations that succeed can respond to market changes faster and are poised to exploit new technologies and opportunities. Ideas and inventions are spreading quicker than ever. Learning how to build collaborative, innovative teams has become a critical skill.

References

  1. Book: Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen
  2. Article and video: “Inspection Without Adaptation Is Pointless” by Gunther Verheyen
  3. Article: “Groupthink: the Brainstorming Myth” by Jonah Lehrer
  4. Article: “The Hard Truth About Innovative Cultures” by Gary Pisano
  5. Article: “Advancing the Science of Collaborative Problem Solving” by Arthur Graesser, et al.

[Note: I first wrote this article for projectmanagement.com here]


Let’s Rewrite the PMBOK

Future PMBOK
Phew, the wait is over! I have been wanting to talk about this for what seems like ages and now the official announcement is out! If you have ever been frustrated by the PMBOK Guide now here’s your chance to fix it.

We are looking for volunteers to write and review the next edition of the PMBOK Guide. However, this will not be just an update, instead a radical departure from all previous editions aligned with PMI’s new digital transformation strategy. That’s all I can explain for now, but more details will be announced when I can say more.

Meanwhile, we would like people with knowledge of the full value delivery spectrum (waterfall, hybrid, agile, lean, etc.) to participate.

The full details of volunteer opportunities and entry requirements can be viewed at the PMI VRMS site Here.

I will be acting as Co-Lead for the initiative, which is like a co-chair role. However, Chair and Co-Chair sounds too hierarchical so we switched to Lead and Co-Lead role to match the new structures we will be embracing.

If we want to change the future of project management I believe the best way to do that is from the inside outwards by doing the work - not from the outside inwards just criticizing. Longtime readers may recall my 2010 post Raise A Little Hell when the PMBOK v5 Update was being commissioned. Since then we developed the PMI-ACP, PMBOK Agile Appendices, and the Agile Practice Guide.

This is going to be different!

Click here to see full volunteer role details.


Review of Product Development Books

Product Development CycleNow that a software “Done” Milestone is more like a Tombstone

If you work in an industry that has digital products and services then the Product Development trend will impact you. As software becomes more critical to business operations and product offerings we are seeing that software projects do not end.

Many organizations are transitioning to become software focussed organizations that offer specialized services. Amazon is a software company with retail (and cloud) offerings. Banks are increasingly digital companies with financial services. The same with insurance, travel, music and even commercial goods. The cost of developing the software in new vehicles is now greater than the cost of the engine. It has become the single most expensive component, even in internal combustion engine vehicles with no autonomous driving features.

These websites and software services will only be “done” development when the company stops being competitive, offering new services or keeping up with technology evolution. At one time getting to "Done" on your software project was a relief, a goal, a milestone, now it is more of a tombstone. It means the product is no longer competing or actively being maintained as technology continues to evolve.

Switching from projects (that are temporary in nature) to products that are designed to be ongoing sounds easy enough - just keep funding the team, but for many organizations it is not that simple. Also, organizations that embrace the whole digital product view still need help governing the ongoing process.

This is where product development books can help. They describe the factors at play and provide ideas for guidance around planning, funding, staffing and governance. As I was working with clients experiencing the transition from projects to products I was lucky to engage with several authors of product-first, #NoProjects books and chat about the challenge areas and potential solutions.

I have written about #NoProjects a few times before:

 

Then when I recently read a third book about product development shift I thought it could be useful to review some of the books in the market. A neat aspect of these books is that they all present different views on the project to product mind-shift and journey.  

Continuous Digital

 “Continuous Digital: An agile alternative to projects for digital business

Allan Kelly, Software Strategy Ltd.; October 2018

Allan’s book was the first I read about switching to continuous product development. I had been following his blog for a number of years and was familiar with his work. However, it was not until reading the book that I saw his points laid out in order with full explanations.

It is a great read, it makes a compelling argument for why a project view of software projects is a flawed model. I loved the explanation on the diseconomies-of-scale for software and why it is actually cheaper in small batches – unlike physical goods.

It offers the best explanations I have heard into why a continuous delivery of features by a stable team is preferable to using conventional project models. It nicely describes the team aspects of knowledge work and offers some good suggestions around funding and governance models.  

Any change in mindset has to happen internally first before we can help others adopt it. Continuous Digital cemented my own thoughts about why good software projects never end. It explained the “Why?” questions at the heart of any shift in thinking and behavior. In the same way, we have to understand the agile mindset before generating any kind of commitment towards it. This book helps set the mindset and Why of #NoProjects so we can start our journey.

 

Noprojects book#noprojects: A Culture of Continuous Value

Evan Leybourn, Shane Hastie, lulu.com; July 2018

I read an early draft of Evan and Shane’s #noprojects about 6 months after I started reading Allan Kelly’s LeanPub drafts of Continuous Digital. While Kelly’s Continuous Digital and his spin-off book Project Myopia focus on explaining the Why with some How topics, #noprojects has more of a team focussed view.

It talks about the history of software development. It explains how we came to run software development with project structures and the inherent issues that came with them. It then outlines the case for continuous development with all the arguments for retaining knowledge, reducing handoff and dependences, etc.

I think it is a great follow-on from Continuous Digital. Obviously, it is designed to be a stand-alone text but, for me, Kelly explains the Why of product development better. Then #noprojects fills in some additional background information and focusses more on the team level implementation. It might just be because I read Kelly’s book first but if you are looking to convince others in your organization about the need for transitioning to product development it is the go-to source. Reading both will provide a great foundation to understand and transition from projects to products.

 

Project to ProductProject to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework

Mik Kersten,  IT Revolution Press; November 2018

I first came across Mik’s work via a podcast he did with Shane Hastie. In the podcast, Mik explained that technologies often follow 50-year cycles and then transform through a tipping point into the next evolution in the way of working.

Organizations that try to continue operating with the old model flounder and fail. Moreover, it is now about 50 years since NATO held the first conference on software engineering and the age of software began. Mik explained he believes we are at that tipping point and transitioning to product delivery will be part of the differentiator for the next wave of successful organizations.

I have an interest in technology evolution stories and learning how ideas spread and then transform our lives. So, the 50-year cycle piqued my interest and I ordered the book. The book delivers and not only does it explain the tipping point we are living through right now, but it gives the best explanation of the digital revolution and need for digital transformation I have read to date. Kudos to Mik. If you want to explain why a digital transformation is necessary, and the implications of ignoring it, Project to Product is a brilliant source.

After this great introduction, the remainder of the book explains the Flow Framework Mik helped develop and promotes through his company Tasktop Technologies. The Flow Framework provides metrics and tools for tracking and managing product development. This is useful because while the project management world has a wealth of information about tracking and managing projects, organizations that switch to product management often experience a void or competing recommendations.

The Flow Framework is useful for explaining what we should pay most attention to tracking. Namely features, defects, risks and debts. It recommends a business outcome set of measures that include: value, cost, quality and happiness. The framework employs a lean inspired set of metrics that include flow velocity, flow efficiency, flow time, and flow load.

It is in the rebranding of tradition lean metrics that I struggle to recommend the book wholeheartedly. By prefixing the normal throughput based lean metrics with the word “Flow” Mik is able to define  specific versions of the terms that are often implemented slightly differently from organization to organization. I can see the advantage of that, but it seems an unnecessary name-grab or overloading of lean terms to create trademark-able terms.

That’s a minor quibble though and what Flow Framework does provide is a good mental model for organizing, executing and tracking your product development process. It nicely extends the pattern of books started with Continuous Digital that explains Why product development. Then #noprojects that provides some team-based and stewardship elements. Finally, Project to Product provides solid How To ideas for ongoing governance and improvement.

 

Summary

These three books form a useful progression for anyone wanting to learn about the product development trend. They each provide valuable ideas to help with understanding, practicing and then managing successful product delivery.

Product Development Books Progression

The books allow readers to understand and internalize the need for a product development mindset. Then how to practice on a small scale before encouraging others to try and providing ways to measure and manage it.

Obviously, you do not need to read all three of them, or in this sequence. Any one of them is a good read and source for practical ideas. However, I found that they build nicely upon each other and thought people would be interested to consider them as complementary.


New PM - The What?, Why?, and How? of Project Charters

Project CharterCreating a great project charter is an art and a science. Anyone new to the profession of project management needs to learn how to create a project charter. It is not only an important early project deliverable, but it also sets the tone and lays out the foundation for the rest of the project.

While we can spend our careers improving our ability to craft effective project charters, we can get to a 70% good-enough state by addressing some basic topics. This article explains those basics.

Context is Crucial
First, it is critical to understand that context matters. The definition of what makes an acceptable—or great—project charter will vary from organization to organization. It will also be driven by factors such as project size, criticality, type, approach, etc.

The project charter for kicking off a safety-critical public works project will be very different than a charter for a small internal project to, say, build a tool to recover disk space used by duplicate files.

Large, critical projects will require large comprehensive charters. These can take teams of experts weeks or months to create. Small projects will likely have their three- to eight-page charter written in a day or two by the project manager. When creating (or reviewing) project charters, we need to understand this context. Ask, what is appropriate? What level of rigor and detail does this effort require and deserve?

To start the chartering process, we first need to understand a few things about the project goals and our internal processes.

  • For the project, we need to understand the business case and an outline of the desired scope.
  • For our organization, we must understand any strategic plans we need to align with, our standards and processes, contracts to use, and any relevant external factors like market conditions and industry standards.

Once we know these things, we can start writing our charter.

Make it Clear
I am a simple person and like simple ideas and definitions. I probably miss subtle nuances but have learned that most people appreciate simple, clear documents. The style points we lose for a lack of sophistication are made up for by improved comprehension and clarity. So, my definition of a project charter is a document that authorizes the project and explains the what, why, where, when, who and how aspects of the project.

We can call the whatwhywherewhenwho questions W5 and add a “+” for the final how question. Provided the project charter answers the W5+ questions and provides approval to start the project—all at the appropriate level of rigor—it’s a winner. So, let’s get started by reviewing each question…

What?
In your project charter, you will not call the section “What?” It will likely be called “Scope” or something similar. The “W5+” idea is just a tool to make sure we address the important sections. So, in the scope section, we would describe or list the major deliverables or high-level functionality the project should deliver. People need to understand what we are talking about before they can appreciate further details such as schedule and approach.

When defining what the project will deliver, it is also useful to state what it will not deliver. So, a list of “out of scope” items is also valuable. It is better to have sponsors or user representatives complain now rather than halfway through the project (or worse, at completion when there is nothing we can do about it) that their anticipated element will not be delivered.

Why?
The why of a project is described in a “Problem Statement” or “Business Need” section. Some people put this section before the what. That is fine; follow your organization’s standard, or the preferred sequence of who approves project charters (or failing those, your own preference). Just make sure the what and the why are addressed early on.

People need to understand why this project is important. What new revenue will it bring? What problem or legal requirement does it serve? What new opportunities, new products or new customers do we hope it will attract? Projects are expensive and risky endeavors, so we better have a good reason to undertake one. The business case or problem statement is where we describe it.

It needs to be clear and compelling. It may reference a separate business case or return on investment analysis. If these components are necessary and not in separate documents, include a summary in the charter body and put the details in an appendix. We don’t want people to stop reading our project charter because they came across pages of calculations.

Where?
“Where?” can seem a strange question, maybe inserted just to get the “W” count up to five. However, think broader. Which markets, products, and departments are we impacting? Where is the project going to touch our organization, customer base, and market segment?

Remember: The project charter normally provides approval for a project to start. We need to provide the relevant context so people are thinking appropriately before they approve, reject or request changes be made.

This information may be contained in a section called “Organizational Impact” or form a sub-section of the scope section. It also explains how the project is aligned with the organization’s strategic plan.

When?
This is where we describe the “Project schedule”—not only when we plan to start and (hopefully) complete the project, but also major steps along the way.

Being a project manager writing a charter, it’s easy to get caught up in the apparent importance of your project. You might assume that once approved, the organization will rush full-steam ahead into kickoff and execution. We need to inject some caution and realism. What seems important and obvious to us is often low priority for the sponsors or those already over capacity in executing existing projects and operations. Things might take a while to get going.

So, do not build a schedule based on starting work immediately after approval. That just sets everyone up for failure. The most common source of late project completions is not poor estimating or a lack of risk management, it is late starts. Every late project I have reviewed had a late start. They may also have been terrible at estimating and blind to common threats, but late starts are very common. We need to explain that real end dates are driven by real start dates.

Projects get delayed for a host of common reasons. We were delayed in getting our team, we were delayed in finding a space, we were delayed in accessing funds. So, do yourself (and everybody else) a favor and explain that the project will likely take three weeks, months or years from having the requisite start conditions.

We also need to be realistic about uncertainty. The uncertainty associated with our estimates needs to be reflected (to some degree) in our schedule. It is probably not acceptable to say, “We have no clue when we will be done.” But do not commit to completing within a certain timeframe unless you have a realistic and robust plan for achieving that.

Robust means including contingency to address uncertainty. Be open about it, such as, “We included a 15% buffer for unanticipated work.” You might get asked to remove it and “work smarter” or “find a way, damn it!” and that is fine. You reflected the uncertainty inherent with the work. Depending how supportive the sponsors are, we could consider explaining that removing contingency is accepting the risk of an overrun due to learning in the future things that we do not know today.

Plans and estimates created at the beginning of the project are, by definition, the least reliable because that is when we know the least about the project. It is only when we begin to execute that we learn about its true complexity and the actual abilities of the team, vendors and supporting groups. Sponsors usually don’t want to hear this kind of smartass insolence from the project managers. PMs are hired to deliver projects, not tell them how to set stretch goals or run a business.

There are other ways to shorten a schedule. We can cut the scope of what is delivered. This could allow us to hit a deadline and maybe have a follow-on release for lower-priority work. It is not ideal and is really wriggling out of the defined scope. However, for software products, where must-have and nice-to-have features are more fluid, it could be a viable option.

We can also add more people to the project. This works great if you are undertaking simple work like digging ditches or building pyramids. For anything more complex that involves problem-solving, idea sharing and collaboration, books like The Mythical Man-Month explain that adding people to a project that is late will make it later (while spending more, too).

For these reasons (and others learned the hard way), make sure schedules clearly contain contingency to reflect uncertainties. Also, ensure that schedules work from a project start date that is contingent upon having prerequisite project conditions in place. Yes, they might both get ignored, but it is the responsible thing to do—and you can bring them up at steering committee meetings when asked why the project is behind.

Who?
The who question represents the “Team” and “Stakeholder” sections of a project charter. It is normal to show org charts of core project roles and list known team members and open positions. RACI charts can be used to list who is responsible, accountable, consulted and informed (RACI) for work and deliverables.

We should understand that the term stakeholder encompasses not only the people working on the project and sponsoring it, but also everyone it will impact. This extended family of project influencers include suppliers, customers, and even the general public if the project is likely to draw public opinion. Obviously, we do not list these broader communities by name, but we should identify them and assign a contact within the project for managing that group.

The PMI definition of a stakeholder includes not only those impacted by the project, but even those who perceive they may be impacted by the project. This is important—the scope of people who may influence development is wide. It is better to have a plan for engaging or at least monitoring these groups (be them environmental, minority or special interest) before they can blindside the project. Inventing a fire-response plan is always easier to do before you also have a fire on your hands.

How?
The how question reminds us to explain the “Project Approach.” We should describe how the project will be executed. Will we be following the standard corporate project lifecycle? Are we trying a new approach? Are we outsourcing portions?

People need to understand how the project will be executed before agreeing to fund it or participate in it. If they think the project has merit but we are suggesting to go about it all wrong, they will want the ability to influence the approach used.

When we are following a standard approach, it is sufficient to just name it. When we are proposing something different, we need to describe it in more detail. This could be a reference to another document or pointer to an appendix in our project charter.

Approval
The charter describes the project from a holistic perspective by addressing the W5+ questions; it also provides the approval/authorization to start work. In most organizations, approval of the charter triggers a request for funds or authorization for expenditure (AFE). For this reason, we need some formality around the approval and sign-off of the charter. It is normal to have a signature section for sponsor, division leads and other steering committee members.

The approval circumstances are rarely as simple as either approved or not approved. It is usual to have definitions of the various options that the steering committee may use. Common status options include:

Approve – Looks good, let’s get started
Approve with modifications – Will be okay if you make these changes (provide some space in the signature area to hand-write requested changes and then get signatures)
Request changes – Major changes are required and a new charter will need to be submitted
Defer – Not at this time, keep on hold
Reject – No, do not proceed

What about agile projects that do not have charters?
Today’s agile projects produce fewer documents. However, since charters often authorize work to start and trigger the release of funds, we still sometimes see them used in hybrid traditional/agile environments. If project charters are not used in name, typically a lighter-weight deliverable with a different name is used.

We might see an Agile CharterProject Skinny or Product Canvas. The purpose is similar—describe the endeavor and get agreement to start. When working with agile approaches, we can still use the W5+ idea to make sure we address the common viewpoints. The coverage in each section will likely be brief, but is still helpful.

Summary
Consider the context you are working in. Organizational standards and project characteristics such as size, cost, and impact of failure will dictate the level of detail and rigor that will be necessary. Then keep the sections simple and clear. Use appendices or references to external documents if sections become too long. We want people to be able to read the core body of our charter through in one sitting and then make a decision to approve it.

Make sure the sections address the W5+ views of the project one topic at a time. For instance, do not mix schedule with business justification; keep them separate. Do not paint yourself into a corner by committing to unrealistic delivery dates or optimistic costs. Present what you believe is realistic and let the steering committee assume the risks of reduction (if possible).

Recommending a template is problematic since organizational needs vary, but common sections for a small- to medium-sized project might contain:

  • Introduction – Explain the purpose of the charter
  • Problem Statement – Outline the what
  • Scope Outline – More detail on what would be delivered
  • Definition of Success – Define what “done” would look like
  • Risk Summary – Review the high-level threats and opportunities identified
  • Constraints and Assumptions – Outline the accepted operating parameters used
  • Business Case – Explain why the organization should do this
  • Schedule – Explain when the project will be completed
  • Deliverables Schedule – Outline when the key deliverables will be completed
  • Budget – Explain how much this is likely to cost
  • Team Structure – Outline who will be working on the project     
  • Organizational Structure – Explain who will be responsible for oversight and direction
  • Project Approach – Explain how the project will be run
  • Steering Committee Decision – Record the approval (or otherwise) of the charter
  • Appendices
    1. Project Background – Supporting material about why this is a good thing to do
    2. Deliverables List – A list of what should be delivered and what Done looks like for each
    3. Deliverables Schedule – A schedule for the deliverables’ leave some wiggle room
    4. Risk Assessment Detail – Details of the threats and opportunities analyzed to date
    5. Communication Plan – Details of how people will be kept informed about progress and issues

[Note: I first wrote this article for ProjectManagement.com here ]


New PM, New Choices

Choices(Over at ProjectManagement.com January’s theme was “New PMs”. I wrote this article about the choices of approach we have and ways for new PMs to navigate them.)

These days, new project managers are exposed to conflicting guidance. On the one hand, there is a plethora of traditional “Plan the work, work the plan” literature. On the other, media is full of light-touch, self-organizing team advice. These sets of recommendations often appear to be at odds, so what is the new PM to do? Consultants will say, “Oh, it depends…” and start a lengthy (aka expensive) conversation. I say let’s examine the basics so we can make an informed decision ourselves.

The goals of planning, scheduling, and tracking are universal. We need to understand what work needs to be completed, determine a good way to do it, then make sure it happens while making adjustments as new information emerges. However, in the last 30 years, we have started tackling more projects with higher degrees of uncertainty and change. These characteristics help us determine if we should use traditional, predictive approaches or rely more on newer, adaptive techniques.

When our projects undertake defined, repeatable work using technologies and approaches our organizations have experience in, then uncertainty and change rates are typically low and manageable. Here, traditional project management approaches work great. It is safe and effective to use Gantt charts, detailed work breakdown structures (WBS), network diagrams and earned value analysis.

Yet when projects use new (to us) technology and tackle problems our organizations have not solved before, then risk, uncertainty, and rates of change will be high. Traditional approaches have plenty of tools for handling risks, uncertainty, and change; but modern, adaptive approaches were purpose-built for these types of projects and have proven to be effective in these circumstances.

Work Characteristics, Not Industries
It is important that we examine work characteristics, not just the industry domain we are operating in. It would be easy (and wrong) to classify all construction projects as candidates for traditional approaches, and all IT projects as needing an agile approach. Instead, there are plenty of experimental construction projects using new designs, materials and assembly approaches. Likewise, there are defined, repeatable IT projects that can (and have been) successfully managed using meticulous planning, detailed estimation, and formal change control procedures.

So we need to dig deeper and see if we are dealing with low-variability tasks or more consensus gathering and problem-solving. These work types often change depending on which phase of a project we are working on. Designing something is typically a consensus-gathering and problem-solving exercise. Here, formal planning and estimation are difficult because we don’t know what we will encounter.

Consider the process of designing a new car or home. We have a combination of creative goals (produce something new and appealing) and engineering goals (meet specifications, constraints). The process is likely to be iterative and adaptive. We are looking to build consensus between stakeholders, who include sponsors (concerned with value, schedule, quality), designers (aesthetics, features) and engineers (performance, practicality).

This design phase requires collaboration between subject matter experts and probably iteration on prototypes to confirm understanding and validate ideas. Approaches like lean, kanban and agile work well in these uncertain, high-change environments. Their tools for experimentation, rapid feedback, reprioritization, and improvement help generate consensus on designs and drive uncertainty out of models.

Then, once the design is agreed upon, the process of production is typically more defined and repeatable. Unless our car or home is using new technology, materials or assembly techniques, the process of actually turning designs into completed examples should be less uncertain and iterative so more predictive approaches to work management can be used.

Physical projects—which manipulate tangible materials like concrete, steel, and plastic—have significant production phases where predictive approaches can be employed effectively. Digital projects—which manipulate intangible data and algorithms—have no production phase since the process of turning code into executable software (the process of compiling code) is automated.

Physical Project Characteristics

So, software projects remain in the design phase—that early, upfront, uncertain period where subject matter experts are collaborating to create something that has likely not been done before.

Digital Project Characteristics
There will be many trade-offs between design goals and implementation practicality to be made. All the divergent stakeholders will have divergent goals. The sponsors want fast, cheap and high quality; the users want their work simplified and streamlined so they can focus on their goal. The development team wants interesting work using new technology and skills to further their craft.

Once we understand what work types suit predictive and adaptive approaches, we can make better sense of our projects. Having said software development is design phase focused, it’s important to understand most IT projects do more than just software development. Tasks like ordering equipment, installing hardware and training users can all benefit from predictive planning and management techniques.

A Case Study
A couple of years ago, I worked on a project to develop and install routing software for truck drivers. This combined custom software development, integration with commercial off-the-shelf (COTS) software, and hardware installation that required wiring into the truck’s engine management system and installing GPS transmitters, tablets, etc.

The custom software development was easy to plan (but not easy to do). It was new, uncertain and benefitted from an agile approach. Integrating with the COTS software was a hybrid process. We worked with the vendor to iteratively tackle the highest risk and highest business value portions first. However, being just one customer of many, the vendor did not have the availability to serve our needs as quickly as we would have liked.

We worked on a monthly delivery cadence maintaining a backlog of issues and features to tackle next. Due to previous disputes about charges, the working relationship with the vendor was quite adversarial—so detailed statements of work and a formal change control process was followed. This consumed quite a bit of time for both parties, time that could have been focussed on feature development—but that reflects the reality of many commercial projects. We have to make the best use of what we have, given the current circumstances.

Installing the equipment in the trucks demanded precision timing, OCD levels of planning and copious communications. Semi-trucks cost hundreds of thousands of dollars and are carefully scheduled to make the most of their time. Bringing them in from a wide distribution area and having them out of commission while installs are performed (and drivers trained) is an expensive exercise.

When there are several hundred trucks spread across the United States and Canada, scheduling install teams and trucks to come to install/training centers becomes a variation on the traveling salesman math problem. Minimizing the total cost of lost trucking time, travel costs and staff time is a classic traditional planning problem.

In summary, like most real-world projects, the environment was complex and required using a variety of approaches. The custom software development was in-house and under our control. We used an agile approach with team-led sprints, demos, retrospectives, adaptation etc. The integration with the third-party package software was more of a hybrid approach. There were monthly deliveries based on a backlog we prioritized, but also statements of work and formal change requests.

Finally, the hardware installs and driver training was handled in a traditional, predictive way. Schedules for installs, equipment, and labor were planned and communicated well in advance. We did adjust these plans based on findings from early installs, but traditional, waterfall-style plans have always been amenable to minor adjustments. Software updates were delivered to the trucks over-the-wire as the trucks communicated back to base, so the agile teams could get new versions distributed once the equipment was installed.  

Making Informed Choices
Assessing uncertainty and consensus-gathering needs are important factors in determining the most appropriate approach to use. Thinking first about uncertainty, well-understood, often repeated work (such as building a new Costco store) represents much less uncertainty than rare endeavors such as building an underwater hotel:

Project Uncertainty

If we add to this uncertainty view the dimension of approach focus, we arrive at a framework for assessing project approaches (shown below):

Approach Focus

The “Approach Focus” Y-axis describes if techniques (approaches) are technical, such as creating a work breakdown structure (WBS); or people-focused tasks, such as team decision making or conflict resolution.

Using this framework of project uncertainty and approach focus, we can see that traditional, predictive approaches cover the bottom left quadrant of the graph well. They are great for work we are able to define and provide good process guidance:

Traditional Approach

Agile approaches tackle the problem space from the opposite corner. They are best suited for projects with high degrees of uncertainty and offer good people-based guidance:

Agile Approach

There is a large overlap, too; it represents areas where we could use a traditional approach or an agile approach. Usually, it is recommended to use the approach the stakeholders will be most familiar with. So, if we are running with an agile team, a risk-adjusted backlog and risk burndown chart will likely be an easier sell than traditional risk management approaches. Likewise, if we are in a traditional, formal contracting environment, then statements of work and bills of materials will be accepted more readily than agile alternatives.

Summary
We can use the project environment to help determine which execution approach to use. Obviously, there will be organizational standards and guidelines to be aware of, too. However, even within traditional or agile guidelines, we can tailor our approaches based on uncertainty and task focus.

New project managers should understand that traditional project management has a wealth of process-oriented guidance for well-defined tasks. Likewise, agile offers much for uncertain, high-risk work that focuses on collaboration and people-based tasks.

We should also be aware that real projects are messy, complicated affairs. We often use a combination of approaches at macro and micro levels to try and be successful. It sounds complicated, but it forms the mastery of being a great project manager and is a journey worth pursuing.

[Note: I first wrote and published this article on ProjectManagement.com here]

 


PMI-ACP Exam Prep Course with Mike Griffiths, Calgary, Alberta

Pmi-acp_exam_prep_cover_2nd_ed_updatedI am gathering names for my next Calgary based PMI-ACP Exam Prep course. Please let me know via email to Mike <at> LeadingAnswers.com if you are interested in reserving a spot on the next 3-day Calgary based PMI-ACP Exam preparation course held late May / early June 2018. We can do Wed, Thu, Fri or Thu, Fri, Sat – let me know your preference.

 

Evolution of the PMI-ACP Credential

Popularity has grown in the PMI-ACP from niche to mainstream with over 20,000 people now holding the credential. This makes it the most popular experience based agile certification and the credential of choice for hiring managers looking for the rigor of a ISO 17024 backed PMI credential. 

On March 26, 2018 the PMI updated the exam to align it with the lexicon of terms used in the new Agile Practice Guide. The course features updated materials and the new Updated Second Edition of my PMI-ACP Exam Prep book as an accompanying textbook.

 

My Involvement in the PMI-ACP Credential

I was a founding member of the steering committee that designed and developed the exam content outline for the exam. We based the exam on what agile practitioners with a year or two’s experience should know to be effective. We wanted a methodology agnostic credential that captured the agile practices used on most projects most of the time. The exam covers Lean, Kanban and agile approaches such as Scrum and XP along with servant leadership and collaboration. 

I worked with RMC to write their best-selling PMI-ACP Exam Preparation book. I recently updated this book to align it with the March 26, 2018 lexicon harmonization and change the chapter review questions to situational questions. The book is available from RMC here and is also included in the course.

 

Details about the Course

The course will be capped to 20 people for better Q&A and will likely take place at historic Fort Calgary which is close to downtown on 9th Avenue, has great catering and free parking. It includes the new Updated Second Edition of my book, colour printed workbook, sample exam questions, and additional materials. 

The course has a 100% pass rate and uses Turning Technologies audience response (clicker) technology to privately track your strength and weakness areas as we go. Following the course, each participant receives a personalized follow-up study plan based on their sample question performances. For more details see the Course Outline.

To express an interest and get pricing information please contact Mike <at> @LeadingAnswers.com.


The Importance of Focus

Edison BulbI have an old-fashioned Edison bulb desk lamp. It’s to remind me to focus (and because I like steampunk, industrial design). A 40-watt incandescent bulb will barely light a room, but a 40-watt laser can cut through aluminium, leather, and wood. It is the same amount of light energy, just focussed instead of being diffused.

The same principle applies to our attention, work and teams. Diffused and scattered there is not much impact. Focussed and concentrated that energy is very impactful. Removing distractions and focussing on a single deliverable at a time allows us to complete our work faster with fewer defects.

Aligning a team to a common vision and purpose directs their energy towards it. No longer diffused to fulfil a dozen competing demands, effort is channelled to the shared goal. Distractions come in many forms. Fancy tools, cool architecture, requests from different groups. If we do not pay attention to focus, our laser beam team becomes an Edison bulb, it is busy and glowing, but not very effective.

So, be cautious of distractions. Monitor time and energy directed to the project goal compared to energy directed to peripheral activities. Work life is like a greased pole with a 40-watt Edison bulb at the bottom and a 40-watt laser at the top. We must always be striving upwards to focus because as we relax we slide down towards distraction.

(Also visible in the picture is my “Do The Work” Post-it. another reminder to focus and a pointer to work on the same topic by Seth Godin and Stephen Pressfield. I guess I could get a 40-watt laser too, but that would scorch the cat rather than amuse it. Plus yes, it is snowing here and yes, my windows are old)


New PMI-ACP Workbook

PMI-ACP WorkbookI am pleased to announce the availability of my new PMI-ACP Workbook. This new workbook focusses on a smaller subset of 50 key topics.   My original PMI-ACP Exam Prep book distilled all the relevant content from the 11 books on the PMI-ACP recommended reading list in a common voice. The workbook is also different by providing lots of exercises and many situational questions like you will find in the exam.

So, while my PMI-ACP Exam Prep book covers all the background and theory – ideal for a comprehensive coverage of everything in the exam, the new PMI-ACP Workbook is a practical, hands-on study tool that focusses on the core topics needed to pass the exam. If you already have your CSM credential or 3+ years of agile experience you likely know the agile mindset, values and principles material already. However, you may not have the lean, kanban, and team development knowledge needed to pass the PMI-ACP exam so the workbook can fill those gaps.

To help determine which book is best for you I created the following flowchart:

PMI-ACP Workbook Flowchart

Hands-on learners and people who do not want to read all about how the approaches fit together will find the 50 key topics of the new workbook a simpler way to navigate the material. Also, since the content is arranged by topic alphabetically you can easily jump around and create your own study plan based on just the topics you need.

While the workbook coverage of topics is less than the prep-book, the emphasis on exercises and situational questions is much higher and accounts for the slightly higher page count (457 pages). There is white space for writing notes and the whole thing is spiral bound so it lays flat when you are working in it. The content changes are summarized by these rough page count graphs:

PMI-ACP Book Contents

I think it fills an important need. A workbook for hands-on learners looking to build their own study plan and gain access to high-quality situational questions. It also provides access to a free online quiz. Readers can order and get an early-bird discount from RMC here.

 

 


The Business Analyst and the Product Owner


BA and PO rolesIn my last article we talked about the role of the BA on agile projects, reviewing what stays the same and what changes from traditional approaches. In this article, we will review the contentious topic of how the role of the BA varies and overlaps with the Product Owner (PO). We cover the similarities and differences including danger signs such as “BA as PO Go-Between” and positive patterns such as “BA as PO Supporter”.

 

The Product Owner (PO)

First, let’s make sure we understand the role of the Product Owner (PO). It originated in Scrum but is often also used beyond Scrum in other agile approaches and hybrid approaches. The Scrum definition of the role is the person responsible for maximizing the value of the product and the work of the development team. This includes being responsible for managing the Product Backlog. Extreme Programming (XP) has a similar “Customer” role, DSDM has one or more “Business Ambassadors” depending on the scale of the project. They all play a similar role in stewardship of the backlog, including:

 

  • Ensuring that the product backlog is visible, transparent, and clear to all, showing what the team will work on next
  • Ensuring the team understands items in the product backlog to the level needed
  • Clearly expressing the product backlog items
  • Ordering the items in the product backlog to best achieve goals and outcomes
  • Optimizing the value of the work the team performs

 

Benefits Beyond Backlog Management

In addition to this backlog focused work, the Product Owner is often the primary interface to other business stakeholders. They help teams gain access to business subject matter experts for insights on topics where the Product Owner may not have all the answers. They also often act as a gateway to funding, making the business case for additional funding requests, or as a powerful ally when asking for roadblocks to be removed. Playing the “Business is asking for X” card is typically stronger than the “Team is asking for X” card when asking for an exemption from process, or to expedite an issue.

 

Continue reading "The Business Analyst and the Product Owner" »


When Outsourcing Makes Sense

When to Outsource GridDisclaimer: This article is based on my personal experience of software project development work over a 25 year period running a mixture of local projects, outsourced projects and hybrid models. The data is my own and subjective, but supported by 1,000’s of industry peers I question while delivering training courses for the PMI. I do not work for a local based or outsourcing based company, I have nothing to gain from favoring either approach, but I hope these thoughts are useful for determining some of the pro’s, con’s, true costs and circumstances when outsourcing is better or worse than local development.

To the uninitiated, outsourcing seems like a great idea. Software engineers are expensive in many countries but much cheaper in other parts of the world. So, since software requirements and completed software can be shipped free of charge via email and web sites, why not get it developed where labor rates are much lower?

Coding vs Collaboration Costs

The flaw in this plan comes in the execution of it when it becomes apparent that software development projects typically entail more than just the development of software. Writing code is certainly part of it, but understanding the problem, agreeing on a design, discovering and solving unforeseen issues, making smart decisions and compromises to optimize value and schedule are big parts of it too. This is the collaboration effort part of a project. Also, while the coding part might represent 30-50% of the overall project costs, these shrink to 20-30% when a 3-year ownership cost view is considered that includes support, maintenance and enhancements.

Sticking with just development costs for now, let’s examine a scenario. The business case pitched to executives by outsourcing companies initially seems very compelling: Project Alpha needs 9 months of software development by a team of 5 people. If you work in an expensive labor market, like North America, we can assume fully-loaded hourly rates of $100 per hour, yet highly qualified consultants from our fictional outsourcing country of TechLand cost only $25 per hour. So, the project for 9 months x 160 hours per month x 5 people at $100 per hour in an expensive market costs $720,000. For a TechLand team this would cost 9mths x 160hrs x 5pl x $25hr = $180,000, that’s a cool $540,00 saving, right?

Let’s revisit this scenario based on the acknowledgment that the actual software writing part of a project is closer to a 30-50% of the total effort. This leaves the remaining 50-70% of the work as the communications heavy collaboration part. It should come as no surprise that separating people via distance, time zones, and potentially language and cultural barriers increase communications effort and propagates issues up the cost-of-change-curve

So, when 50-70% of the communication-heavy collaboration work takes longer, how do we quantify that? Agile methods recommend Face-to-Face communications because it is the quickest, conveys body-language and provides an opportunity for immediate Q&A only for the issues that need it. Switching from Face-to-Face to video, conference call, email or paper create barriers and adds significant time and opportunity for confusion. A 2-3 X increase in effort likely downplays the true impact when considering the costs of fixing things that go awry because of inevitable misunderstandings, but let’s use that number.

Redoing our project Alpha costs with, say, 40% as the actual coding effort and 60% effort communications heavy collaboration work that takes 2.5 X as much effort we get: 9mths x 160hrs x 5pl x $25 hr x 40% = $72K Coding + 9mths x 160hrs x 5pl x $25 hr x 60% x 2.5 = $270K Collaboration giving $342,000 in total. However, this is less than half the costs of the $720,000 locally developed project so we are still good, right?

The Compounding Costs of Delay

An error in the logic applied so far is that this 2.5 X communication and collaboration penalty on 60% of the work can somehow be magically absorbed into the same 9 month timeline. In reality these outsourced projects take longer because of the increased communication and collaboration effort and 2.5 x 60% = 1.5 X as long is consistent with my experience from 25 years of mixed local and outsourced projects.

Continue reading "When Outsourcing Makes Sense" »


PMI-ACP Training in Calgary

CalgaryI am testing demand for another Calgary based PMI-ACP Exam Prep course. Please let me know via email to Mike <at> LeadingAnswers.com if you are interested in attending a 3-day Calgary based PMI-ACP Exam preparation course. 

 

Evolution of the PMI-ACP Credential

I ran a couple of Calgary based PMI-ACP courses three years ago when the exam first came out. Since then the certification has grown in popularity from niche to mainstream with over 10,000 people now holding the credential. This makes it the most popular experience based agile certification and the credential of choice for hiring managers looking for the rigor of a ISO 17024 backed PMI credential. 

In October 2015 the PMI rolled out the updated version of the PMI-ACP exam, based on feedback from hundreds of existing credential holders and agile practitioners. The new Exam Content Outline has been restructured with the addition of a new domain “Agile Principles and Mindset” to focus on thinking and acting in an agile way as opposed to simply implementing agile processes and hoping for improved results.

 

My Involvement in the PMI-ACP Credential

I was a founding member of the steering committee that designed and developed the exam content outline. We based the exam on what agile practitioners with a year or two’s experience should know to be effective. We wanted a methodology agnostic credential that captured the agile practices used on most projects most of the time. The exam covers Lean, Kanban and agile methods such as Scrum and XP. 

I worked with RMC to write their best-selling PMI-ACP Exam Preparation book. I recently updated this book to restructure it to the new Exam Content Outline. The book is currently available for 30% off from RMC here and is also included in the course.

 

Details about the Course

The course will be capped to 15 people for better Q&A and will take place at historic Fort Calgary which is close to downtown on 9th Avenue and has free parking. It includes the second edition of my book, colour printed workbook, sample exam questions, and USB stick of additional materials. 

The course has a 100% pass rate and uses Turning Technologies audience response technology. Following the course each participant receives a personalized follow-up study plan based on their sample question performances. For more details see the Course Outline.  To express an interest and get pricing information please contact Mike <at> @LeadingAnswers.com.


Agile Talent Management

Talent ManagementTalent Management is the science of human resource planning to improve business value. It includes the activities of recruiting, retaining, developing and rewarding people along with workforce planning. From an agile perspective much of what we do on agile projects helps with talent management. We encourage empowered teams and give people autonomy over how they work which improves satisfaction and motivation. We also promote knowledge sharing through a variety of collaborative practices which reduce the impact to the team of people leaving. 

However, these measures only address some recommendations for talent management. This article examines the ideas and project implications of the other recommendations. First, let’s examine why talent management is important and understand the labor cost vs opportunity cost differential. 

Recruiting costs

If we lose a team member and need to replace them; a job posting needs to be created and sent out to agencies and online forums. We then need to sift through replies and come up with a short list of candidates to consider further. Next comes reviewing candidates with the project manager, arranging interviews, interviewing candidates (preferably with team involvement), following up on references, salary negotiations and hopefully finally hiring someone. I went through this recently for a developer on a software project and estimated the total time to the organization to be 64 hours. At an average labor rate of $80/hr that is $5,120. Had our first choice candidate not joined or failed reference checks the total time to hire would be much higher. 

Getting up to Speed Costs

A point often overlooked is not this initial hire effort, but the subsequent, much larger learning cycle before becoming a productive team member. A convenient Tayloristic view of management believes one developer can be swapped out for another. However, for a large, complex project it often takes smart, motivated individuals 3 months of learning to get up to speed with the business and technical domain and a further 6 months before they become truly productive. In these first 3 months not only are they not contributing to net new functionality but they are spending 50% of their time asking questions of other team members – slowing their output too. 

These costs are huge, assuming a fully loaded developer rate of $80 / hour (typical for North American software engineering) 3 months of not contributing and slowing other developers by 50% full time equivalent (FTE) costs: 3m X 4.2wks x 40hrs x $80/hr + 50%(3m X 4.2wks x 40hrs x $80/hr) = $60,480.

Follow this with 6 months of increasing capability going from 0% productive (no longer a net drain) to 100% productive (up to speed) we can use an average figure of 50% non-productive so 6m x 4.2wks x 40hrs x $80/hr x 50% = $40,320 

So, the cost of losing a team member and having to recruit and train another could easily be $5,120 + $60,480 + $40,320 = $105,920. However it gets worse, whenever a high performing team loses a team member they move from the Tuckman “Performing“ phase to the ‘Storming” phase again as the team dynamics change and have to get back through “Norming“ to “Performing”. 

Continue reading "Agile Talent Management" »


Agile Innovation

Psst, this is your conscious, I am here to remind you about something you have thought about, but then hid away in the back of your mind. Lots of this agile stuff is hypocritical, it preaches evolution and change, but then we ask the same old three questions at standup every day. Also, why must we have standup every day, isn’t that kind of prescriptive? Agile methods are supposed to facilitate innovation through iterative development followed by inspection and adaption. They practice the scientific method of measurement and feedback on products and team work; so why are the agile practices themselves magically exempt from this precious evolution?

I believe there are two main reasons; first off, it is to protect inexperienced agile practitioners from themselves. With a free rein to morph product and process there is a strong likelihood that by six months into a project the practices followed by the team would have deviated from the proven and tested methods of most successful teams. The risk of failure would increase and every project in a company would be using a radically different approach making integration, scaling and team member transfers a major problem.

The other reason is a little more sinister. Most of the creators, proponents and promotors of agile methods have interests in keeping the methods pure vanilla. This is so they can create training courses, certifications and web sites for them. While scrum, as one example, has its specialized ceremony names and products you can neatly market services for it. If you allow or encourage people to change it then the result is not so proprietary and more difficult to defend, promote and assert ownership over.

I am not suggesting we should be changing agile methods willy-nilly, I think a basic suggestion to try them out-of-the-box for a couple of years is sound advice. However, beyond that I believe there are great opportunities for growth and deviation outside the standard agile models for stable teams who want to evolve further. This article tells the story of one team that did just that and what other people can learn from it.

Continue reading "Agile Innovation" »


Agile and Strategic Alignment

This month’s theme at ProjectManagement.com is “Strategy Alignment/IT Strategy.” This can seem at odds for agile teams who organically grow solutions towards evolving requirements. Where’s the strategy in that, and how do we promote empowered teams while preventing chaos? Most organizations spend considerable time and effort developing strategic roadmaps and they don’t want this work undermined by unordered development.

Fortunately, hope is at hand with some well proven models. While the common kernel of agile practices make little mention of strategy or architecture, many of the supporting guides and scaling approaches handle the topic well. So, when faced with a criticism of no place for IT strategy or struggling to link an existing strategy to an autonomous team we can turn to these agile “wrappers” for inspiration and guidance.

You do not have to be using these approaches as standards at your organization to make use of the integration points and approaches they recommend. Instead see how strategy and architecture are handled and then apply a similar approach in your project and organization.

DSDM

Dynamic Systems Development Method (DSDM) is an agile approach that started in Europe and covers a broader project lifecycle timeline than most agile methods. It starts early with Feasibility and Business Study phases goes beyond deployment to handle Post Project work. Unlike most agile methods that don’t mention architecture DSDM has an architectural deliverable called the System Architecture Definition (SAD) that is created early on in the Business Study phase.

Agile projects struggling to appease architecture groups and facing criticisms of lacking strategic alignment, could look to the DSDM System Architecture Definition as a template for an early project, light-weight solution. DSDM also fits well with The Open Group Architecture Framework (TOGAF) standard and there is a White Paper on DSDM and TOGAF Integration White Paper here.

SAFe

The Scaled Agile Framework (SAFe) is a knowledge base for implementing agile practices at enterprise scale. It presents this information through a Big Picture View that shows how the work of agile project teams can be rolled up into programs with their own program backlogs. Then explains how programs fit into larger portfolios that implement product investment and strategic themes.

Continue reading "Agile and Strategic Alignment" »


Agile 2015 Conference Session

My presentation outline “Eat Risks for Breakfast, Poop Awesomeness All Day!” was accepted for the Agile 2015 Conference in Washington D.C., August 3-7. As much of the agile community seems engaged in scaling debates I am really happy to share some useful tools that can be used on any project, regardless of approach.

The learning objectives for the session are:

  • See why project managers are the least equipped to effectively identify and manage project risks.
  • Learn engaging ways to educate team members about risk management including identifying threats to avoid and opportunities to exploit
  • Preview 5 collaborative games for effective threat and opportunity management from planning and identification, through management, to reporting and closure
  • Understand the untapped potential of an increased emphasis on opportunity management
  • Review case studies of projects teams that have been using these practices for three years and are achieving measurably better results than teams that do not

Risks_monster_color


Quality Project Management

Unexpected SuccessHow do we define quality as a project manager? Is it managing a project really well, or managing a successful project? How about managing a successful project really well, that sounds pretty good. However it poses the next question: What is a successful project? Let’s look at some examples of project success, failure and ambiguity.

 

Apollo 13
Apollo 13, the third manned mission by NASA intended to land on the moon that experienced electrical problems 2 days after liftoff. An explosion occurred resulting in the loss of oxygen and power and the "Houston, we've had a problem" quote from astronaut, James Lovell (that is widely misquoted as, "Houston, we have a problem".)

Apollo 13
The crew shut down the Command Module and used the Lunar Module as a "lifeboat" during the return trip to earth. Despite great hardship caused by limited electrical power, extreme cold, and a shortage of water, the crew returned safely to Earth and while missing the main moon-based scope, it was a very successful rescue, allowing for future missions. Clearly, this was a remarkable achievement, but the original project goals were not met. Lovell now recounts this story at PMI conferences under the very apt title of “A Successful Failure”.

 

Continue reading "Quality Project Management" »


The Evolution of Teams

The Evolution of TeamsMy other workshop submission for the Agile 2015 Conference is titled “The Evolution of Teams” and examines one team that stopped doing the traditional agile practices is more agile than ever.

Agile practices such as daily stand up meetings, sprint planning and retrospectives are great tools for encouraging team members to share information, collectively make decisions and improve. However, how do you maintain active participation for long periods without burn-out or boredom?

As companies recognize the productivity of high performing teams and bring new projects to established teams rather than disband and reform teams, how do we keep things fresh? My session is a case study of an award winning agile team that has been delivering projects for over 7 years. It examines how the original core practices that are familiar to any team starting agile have evolved into new practices while honouring the original values and goals.

A casual observer may be concerned: “What, no stand-up meetings, sprint planning meetings or retrospectives? You guys are not agile at all!” However teams can be agile without doing the traditional agile practices. Agility, after all, is a mindset not a To-Do list, and this session introduces the practices of “Show-and-tell”, “Tech-talk” and “Sense-Pull” amongst others.  They may not work for your team, but show the journey of one team’s progression through adaptation and refinement of process. (Along with all the bumps, set back and mistakes made along the way too.)

If the presentation gets accepted I will share the main topics of the session here for feedback before delivery.


“Solving Today’s Complex Projects with Agility” Presentation

Gran Canaria PosterNext week, on February 18th, I will be presenting on “Solving Today’s Complex Projects with Agility” at the Society for the Economic Promotion of Gran Canaria (SPEGC), co sponsored by ITProiectus. I have been working with ITProiectus for a while but this will be my first time to meet them and I am really looking forward to it.

The presentation will explain how today’s complex problems can be solved by collaborative teams that  better handle ambiguity than traditional plan-driven approaches. I will review some of today’s wicked project management challenges and show how agile methods, while they look deceptively simple, actually harness sophisticated approaches for generating consensus and driving towards high quality solutions. 


Helping Your PMO Help You

PMO Agile CoordinationDo any of these traditional PMO scenarios match your agile team experiences? Your traditional PMO is so laughably outdated that most agile projects ignoring them; other projects produce token deliverables to appease them, but these bear little resemblance to anything actually happening on the agile projects.

The PMO looks for conformance to BDUF (big design up front) methodologies with signoffs to premature speculations about requirements and scope definitions. It reports progress on traditional projects such as being 75% through Requirements Gathering or 50% through Analysis and Design as if these non-value delivering activities are actual progress. Finally, when projects have issues the PMO responds by creating more review and approval groups to ensure competence and adds gates and sign-offs to try and improve quality.

If these scenarios sound familiar to you I would like to ask a follow-on question: How is your agile roll out going? Is the PMO the last bastion of opposition or are you fighting pockets of resistance and misunderstanding throughout you organization? Is the once “no-brainer” decision to switch to agile actually causing some headaches and frustration? If you answered yes to this too, you are not alone.

It turns out the PMO is not usually the problem, but they are a good litmus or canary-in-the-coal-mine for how an agile transformation is going. The PMO’s focus is project execution process, so if you cannot convince this group that agile is the way to go, then how do you plan to convince groups who don’t care about process at all? How about the BA Center of Excellence or the Architecture group, have they fully bought in to your agile approach or are they requesting more formal practices?

Getting the PMO onboard is helpful in convincing these other, more problematic groups that agile methods can be a better way of working. So how do we do that? Well making agile more accessible is a good start. PMO’s often shy away from agile methods since the short iterations and repeating cycles of work do not offer the familiar phases and gates they are used to. In fact interacting with agile team iterations seems as appealing as putting your arm in a spinning concrete mixer.

However we can make the process less daunting by showing how the user story and backlog process works. Take some required deliverable, like a handover document, and create a story for it. Give it to the team and along with a customer proxy (a Product Owner for instance) the story will get prioritized and placed in the backlog. Since it is required for Go Live the story will get selected and worked on by the team prior to the release date – all with PMO limbs intact.

PMO Agile Coordination
 

Another point of confusion around agile methods for some PMO groups is the lack of a visible end point or meaningful progress reporting. They may wonder if iterations just repeat until the customer is happy rather than the specification is complete? Gaining visibility into the process can help by providing retrospective data to the PMO along with story points and feature metrics. By explaining the cadence of reviews and tracking metrics PMOs are assured progress is measurable and all the old favorites like Budget At Completion (BAC) and Schedule Performance Indexes (SPI) can still be obtained.

Helping the PMO helps agile adoption by creating another advocate group. It may be a surprise to some PMs and teams but PMO’s are under a lot of pressure to justify their existence and demonstrate their value add. They are usually very receptive to ways to stay current and support emerging practices.

Investing some time to train them in Product Owner training or Retrospective Facilitation pays dividends since now they can offer these new project services. Project teams will benefit from a more educated and aligned business community and gain impartial facilitators making it easier for all to contribute ideas at retrospectives.

Rather than unaligned PMOs representing an obstacle to agile teams, they really represent missed opportunities for further agile adoption and an indicator that the agile message might be miscommunicated to other stakeholder groups. Spending some time to address their concerns, explain the risk reduction goals of early feedback, and equip them with useful services will pay dividends and ease the larger adoption of agile and lean principles.

(I first published this artice at ProjectManagement.com here)


It is not the Process, Stupid

ProcessEven though Mickey Mouse is the symbol of Disney theme parks he is not really what these locations are about. Agile methods are similarly known by their novel processes and team ceremonies but these are largely irrelevant distractions from the true focus.

Just as Disney is all about manufacturing a positive visitor experience through detailed buildings, social engineering and extensive staff “character” training; agile methods are really about creating a social framework where effective work can be accomplished. This social framework will vary from project to project and enterprise to enterprise. It is a problem solving exercise like building a custom galley kitchen inside a boat not a standardization exercise like force fitting IKEA kitchen cabinets.

I realize that by using analogies to Disneyland and IKEA so early in an article many readers may assume I have finally lost the plot but after 20 years of practicing agile I have had enough with rote methods implementation and attempts to scale through process training that fail. To me agile is about process as much as Disney theme parks are about Mickey Mouse. Yes, they are an easily identifiable symbol, a short cut to identification, but far removed from what the real focus is.

In fact Mickey Mouse cartoons kind of suck and most people would be hard pressed to think of a good one. However, luckily for Disney that is not the point, their real goal is to capture imagination and allow people to explore fantasy environments while spending lots of money, hopefully as part of a pleasurable experience so they will come back and also tell their friends.

Agile methods aim to shorten the time to value and build high quality, positively received products or services by intelligently adjusting behaviors and employing good construction practices. The activities commonly used to do this include:

Sense making – agree information gathering steps and prioritize exploratory work

Short Build / Feedback cycles – iterate through short cycles of Planning, Exploring, Learning and Adapting

Conesus gathering - collaboratively gain consensus on direction, approach and decisions

Prioritization – build mindful to risk reduction and business value

Results oriented reporting – use metrics based on accepted work that give meaningful indicators to likely completion rates

Respect and empowerment – engage in respectful practices that encourage information sharing and organizational rather than personal optimization

None of these things say we need two week iterations, retrospectives or daily stand up meetings. Those tools are suggested practices to start encouraging some of the right behavior, but pursuing them or measuring them misses the real point. Companies that attempt agile transformations through process training typically fail and it is like assessing a Disney theme park by asking “Does everyone have their Mickey Mouse ears?”

I am lucky to work with an agile team that has been together for 7 years. Not that it has taken us that long to finish a project, but instead the business sees the benefits of a high performing team and keeps bringing us new projects to undertake.

[The whole idea of bringing projects to established high performing teams could be the subject of another post . Instead of creating new teams per project and going through the Tuckman stages of Forming, Storming, Norming then hoping to get to Performing, using existing high performing teams bring many benefits.]

The team is the best I have worked with and won a PMI Project of the Year award for the first project they completed. Yet I cannot remember the last time we had a stand up meeting or retrospective. We dropped two week iterations in favor of a continuous pull of features and use cycle time in lieu of velocity or detailed estimation based on points or days. So is the team still agile? An outside observer looking for process or ceremonies might say No; I would say You Betcha! The team embodies the sense making, iterative, consensus driven concepts implicitly. Techniques like prioritization, results oriented reporting and empowerment are baked into every conversation and action.

It would feel weird to wait until the end of a sprint to discuss adaptation of process. In fact the notion of a sprint seems an artificially restrictive and wasteful construct to manufacture. Inter team communications are too important to wait for a daily stand up meeting and team members get an equal say in decisions and spend lots of time in healthy debate, both face to face and with remote team members.

The set up is not perfect and still has room for growth. We could do better at interacting with other groups and our tendency to “fly-under-the-radar” to avoid delays for approvals from other groups also means we miss opportunities to share success stories and spread effective practices to other departments as well as we could. Yet on the whole the group is very effective.

Skills acquisition is often described using the “Shu”, “Ha”, “Ri” progression. In this model new practitioners start with obeying the rules (shu, which means to keep, protect, or maintain), then consciously moving away from the rules (ha, which means to detach or break free), and finally unconsciously finding an individual path (ri, which means to go beyond or transcend).

My point is that agile is not process following. Success is not methods replication, it is not really gaining an agile mindset either, that’s too insular and individual; instead it is creating a working ecosystem for your environment. The ecosystem may have activities that could be labeled as “processes”, but true processes are designed to resist change, they are like robust pipes that force compliance on items that vary. Activities and behaviors are more open to change and support it where it makes sense.

There are some popular tests to gauge if a team or project is truly agile. The Nokia Test and the Scrum Test are good starting points but they still ask if ceremonies like daily stand ups and constructs like iterations exist. These questions miss the true intent of these practices and bring focus to the process. Yet the process is not important and may/should change over time as a team develops, or be adapted to better suit a client. So it is better to separate the process from the behavior we are really trying to assess.

The following questions do not dictate what process to use but look for signs of a healthy, productive project environment.

  1. Does the business value what is being delivering and want to continue with the same group?
  2. Is the team still improving and learning as it works?
  3. Are the increments of delivered work frequent and of a high quality?
  4. Is the project ecosystem healthy?
  5. Is the system receptive to change?

Thinking of behavior and capability rather than process conformance will help organizations deploy and scale their agile adoptions. It might be easier to measure process adoption than underlying competency, but like associating Disney with Mickey Mouse it is not really about the process.

[I first published this article at ProjectManagement.com here]


Thinking Tools for Scaling Frameworks

Light bulbsScaling agile is a hot topic these days. Frameworks like LESS (LargE Scale Scrum), SAFe (Scaled Agile Framework) and DAD (Disciplined Agile Delivery) are in the limelight as too are companies training up ‘’Agile Transformation Consultants’’ to transition entire organizations to agile. However, successful scaling is not easy, it is one thing to put a company through a week’s worth of training and mentoring, but another completely to make lasting changes to working practices and resolve all the issues that get surfaced along the way.

 The logic is simple, when executives see a successful agile project their initial thoughts are often: “Great, let’s do more of this!”, yet the solution is complex. Solving the simple question of “How do we reliably duplicate exemplary performance?” is anything but simple.  Moving from one or two successful agile projects to transitioning an entire organization to use agile methods is a challenging and daunting task.

Factors such as people who do not understand the problems with current practices and a lack of agile thinking are difficult issues to overcome. Strategies for transforming an organization to agile vary. Some favour a top-down education process, others a bottom-up, grass roots initiative.

Should the approach be Buddhist (teach the principles and allow local adaptations) or more like Catholicism (everyone must follow a strict standard protocol)? Insights into these concepts of scaling up agile can be found in the book “Scaling Up Excellence: Getting to More Without Settling for Less” by Robert Sutton and Huggy Rao. 

The authors describe this Catholic vs Buddhist split along with strategies for bridging the two. The In-N-Out Burger chain popular in California takes a very Catholic view to replication where common practices are replicated with very little deviation. This is akin to proclaiming all teams will follow Scrum by the book. The KFC food franchise on the other hand, allows lots of local customization and sells egg tarts and soy milk in its stores in China that are not offered in other countries. This is like explaining the agile manifesto values and principles and allowing variations in team implementation.

There are times when the need for local uniqueness is obvious. Stanford researches tracked a software company who opened offices in Silicon Valley and India. The Silicon Valley offices had bare concrete floors and rough unfinished surfaces to provide a funky, urban-contemporary look. Yet in India rough finishings send a different vibe and some locations have more dust and are impractical for women wearing long saris that quickly get dirty as they drag along the floor. So the company quickly dropped its Catholic approach and installed carpeting.

There are also times when people can suffer from “delusions of uniqueness” when they think they are “special” or more unique than they really are and miss out on some improvement. Brigham and Women’s Hospital had very high rates of doctor customization occurring in its selection of joint replacement products despite no evidence suggesting these new products were any better. It seems doctors just enjoyed trying out new technology - a problem common to many industries.

It is possible to bridge the two poles of Catholicism and Buddhism by using swappable sub-assemblies. Like reusable chunks of Lego, these proven successful components can be used to quickly get the benefits of some standard process while allowing for local customization.

In an agile setting this could be as simple as moving the 9:00am Stand-up meeting to 11:00 to ease co-ordination with a West Coast team, or more sophisticated such as swapping iterations for a continuous pull of features via kanban and DevOps in a high change environment.

When discussing the top-down education or bottom-up change, Sutton and Rao assert that success comes from a ground war not just an air war. During World War 2 commanders often called in bombing raids with the hope of devastating the enemy. Unfortunately only 20 percent of bombs dropped fell within 1,000 feet of their target. More recently with the advent of GPS and laser targeting it is easy to think air wars are now effective. However a review of NATO’s seventy eight day air war on Serbia to stop ethnic cleansing by Slobodan Milosevic concluded it was “a major blunder that the use of ground troops was ruled out from the beginning’’.

All the research and case studies in Scaling Up Excellence find that “Scaling requires grinding it out, pressing each person, team, group, division or organization to make one small change after another in what they believe, feel or do.”

Air assaults are often useful first steps, but are rarely long term solutions. More often, territory must be won inch-by-inch working through issues as they are encountered. This requires persistence, lots of work and slow progress to reliably instill a new way of thinking and working.

For these reasons we should be wary of “agile transformations” that claim to transition an entire organization over a 2 week or 2 month period. This is more akin to an air battle. Yes, maybe everyone in the organization was exposed to some agile training and this is a necessary step, but true understanding and adaption only come through use, failure, learning and growth which take much more time.

Before planning to scale agile (or any other approach) discuss the “Catholic vs Buddhist” and “Air-war vs Ground-war” concepts with those who will be engaged in the rollout. Learn to detect Delusions of Uniqueness and employ Lego Bridging Strategies. These techniques can avoid “Clusterfugs” - an enterprise friendly word used to describe a poorly received transformation and instead can pay huge dividends.

[I first wrote this article for ProjectManagement.com here]


PMI-NAC Conference

PMI-NACOn May 5th I will be presenting at the PMI-NAC Conference on the following topics:

  1. 21st Century Risk Management: Supporting mathematical analysis with social influence
  2. PMO Evolution: Frameworks to Support a Mix of Traditional, Agile and Lean Project Approaches

I am looking forward to the event and will share thoughts and feedback on the sessions here afterwards. Until then here are the presentation outlines:

Presentation 1: ”21st Century Risk Management: Supporting mathematical analysis with social influence”

Today’s complex projects need proactive risk management to stand any chance of executing successfully. Yet, all the steps of: identifying, classifying, analyzing and prioritizing are for nothing if the risks cannot be effectively avoided, transferred, or reduced. These risk avoidance and reduction steps are largely human led activities with success criteria closely linked to social influence.

While the project manager is key to project co-ordination and success, they are rarely the domain experts and instead bring subject matter experts (SMEs) together to collaborate on novel solutions. These knowledge worker projects require a whole team approach to not only risk finding, but also risk resolving.

This session explains the need for proactive risk management and the importance of social influence on risk management. Using case studies, a team approach to risk management to collaborative workshops, new risk visualization techniques, and examples of team risk avoidance and risk mitigation actions are examined.

Presentation 2: ”PMO Evolution: Frameworks to Support a Mix of Traditional, Agile and Lean Project Approaches”

Agile, lean and kanban approaches are a part of the new project delivery toolkit, especially for projects with IT components. The PMBOK Guide v5 published in January 2013 now describes a lifecycle spectrum spanning “Predictive, Iterative & Incremental and Adaptive” approaches. The new “Software Extension to the PMBOK Guide” expands this model with further agile related guidance for project execution.  Gartner Research claims 80% of today’s software projects employ agile methods. So, is your PMO living in denial, or simply living in the past?

Fortunately, a new class of PMO has evolved to support a dynamic mix of traditional, agile and lean project approaches that we can learn from. Using case studies from award winning PMOs, this presentation examines how proactive organizations are tracking diverse project types with common metrics and enablers.


Agile Requirements Uncertainty

Requirements
<I wrote this article first for ProjectManagement.com here as part of their Requirements series>

Agile approaches are often used on projects where the end goals are not fully known or may change during the life of the project. This seems unusual to my engineering PM friends who manage the fabrication of facilities. To them, not knowing what it is you are supposed to be building or letting things change along the way is a sign of poor scope definition, requirements gathering, and change control. I hear quips from them along the lines of: “You guys need some rigor and decent specifications, maybe then you could build IT systems that work and don’t go over budget!”

They are right of course, for their domain of defined repeatable projects; first establishing a well formed scope definition and complete specification is the way to go. However, many IT projects are not defined, repeatable endeavors, but instead design explorations into unchartered territory for that organization. The mix of technology has not been used that way before. Sponsors have a vision of the end state, but not a lot of specific detail. No matter how much upfront work is done there seems a host of unknown issues that surface during the journey to the destination. Build/ feedback cycles with adaptive plans and progressive elaboration of requirements is the way to deal with these inevitable uncertainties.

These intangible, unprecedented, emergent, evolving characteristics of IT projects are difficult to explain, but need to be understood. They impact how we plan and execute today’s knowledge worker projects as well as how we should manage requirements. When the specifications are clear such as “A kitchen reno with new counter tops and appliances” then simple, signed off requirements can work well. Yet when things are more vague such as “A winter vacation to someplace warm” remaining flexible to changes and new ideas can be valuable.

Let’s look at some of the differences between plan driven, traditional practices for requirements management and those used in agile methods:

Requirements table

Learning and applying traditional methods of requirements management is easy, it is akin to a shopping list approach. We ask questions like “Did you get milk?”, “Did you get the bread?”, “What else do we need?” Changes may be declined or accommodated. “Billy wants some chocolate!” too bad, tell him he can’t have any, or “Oh, I remember we need light bulbs!” We can then ask do we have enough money for light bulbs, do we have time to go find them, etc. It is all pretty much second nature.

Agile requirements management on the other hand is less intuitive. The constant reprioritization, comparison of new ideas with remaining features, and focus on business value has more balls in the air. Like packing a backpack for a multi day camping trip we are always weighing up the benefit verses the size / weight penalty of bringing something along while keeping an eye on an ever changing weather forecast. There is more re-evaluation, more substitutions, more “Do you really need it?” type questions.

Traditional requirements management has a more satisfying progression of closure – Feature A is in the signed off spec, so we are doing it! This is like saying it was on the shopping list so we will buy it. The fact that it may then sit in a cupboard and never be used is a separate discussion. Agile requirements management lacks this reassuring closure since all remaining items are up for reprioritization or substitution until the completion of the project. Our shopping list is being changed as we walk around the store and that makes some people uncomfortable. However, fewer items should go unused.

In the end it comes down to trading off certainty against flexibility and value optimization within your purchasing decision. If you know you want a vacation at the Hotel Del Coronado in San Diego and that ticks all your boxes then you can lock down the requirements early, book it and be done with it. If you are not sure if the twins will be joining you for a vacation and are looking for the best value 4 star hotel; you will want to keep your options open longer and have some flexibility to best satisfy your purchasing needs.


Overdue Update and Designing the Pontiac Aztek

PDCI have had a busy autumn and it has been too long since I posted here. I did some consulting in Europe and attended the PMI Global Congress in New Orleans to present on “21st Century Risk Management” with Dennis Stevens.

More recently our local PMI Chapter won the “Chapter of the Year” award and held their excellent Professional Development Conference that I gave a couple of presentations at. The first on “PMO Evolution: Frameworks for Integrating Lean, Agile and Traditional Projects” and one on “Surviving Agile Projects” aimed at traditional project managers transitioning to manage their first agile project.

The consulting and conference interactions led to a number of ideas for application on agile projects that I will be sharing here in upcoming posts. At our local PMI conference in Calgary last week Bob Lutz, Retired Vice Chairman of General Motors Corporation gave a great talk on design and project management.

He was discussing the importance of defined, repeatable process for efficient, high quality production. Strict compliance and rigorous process controls certainly help improve the manufacturing process. What was interesting was his cautions about applying defined, repeatable processes to design work. He said it flat out does not work and can lead to terrible products.

Bob recounted how upon rejoining General Motors in 2001 he asked Who the hell designed the Pontiac Aztek?(which appears on many Top 10 worst car design lists and is generally slammed from a design perspective – although liked by some loyal owners.) The Pontiac engineers were very defensive claiming that in fact the design of the Aztek was one of the best executed vehicle design projects that had run, hitting each of its targets and assessment milestones during the process. Lutz went on to say while some processes need rigour, design processes need collaboration, feedback and frequent verification to ensure we are on the right track.

As we execute our projects I think there is great value in determining if we are designing something or manufacturing something. The creation of software solutions is like car design, we are trying to understand the problem space and create candidate prototypes for evaluation and evolution towards the best available solution. This requires collaboration, feedback and frequent verification.

Other projects like upgrading servers and training 500 people are more defined, repeatable activities that can benefit from well defined process and strict controls. Most projects I have worked on have elements of both work types mixed together. An important skill for project managers is to know when to employ strict process and when to encourage less structured collaboration where designs evolve based on build-feedback cycles.

I really enjoyed Bob’s talk; he is an engaging speaker who tells things as he sees them and I look forward to reading his latest book “Icons and Idiots”. Over the coming weeks and months I intend to post here more frequently and continue the dialog on the smart application of process and pragmatism.


9 Ways PMOs Can Help Agile Projects

Agile PMOIt may not always be apparent but the goals of the Project Management Office (PMO) and agile teams are well aligned. Both groups want to get to the same destination: namely successful projects and happy stakeholders. However, things often come adrift as soon as the best direction to travel in to get there is discussed. The PMO might expect lots of planning and some documentation to confirm everyone understands the approach. An agile project team might want to build some proof-of-concept models to test feasibility and get confirmation of understanding. So, very quickly the two groups can disengage and have difficulty generating alignment again.

This is one reason agile teams don’t always see the Project Management Office (PMO) as a source of assistance. All too often a traditional PMO can Present Multiple Obstacles, but it does not have to be that way.

First let’s examine what PMO’s are supposed to do. The old roles of: “Rules”, “Tools” & “Schools” goes some way to describing their functions, but a more complete set of offerings was provided in the 2010 PMI Project Management Journal article “Identifying Forces Driving PMO Changes”. These are:

  1. Monitor and control project performance
  2. Develop and implement standard methodologies, processes, and tools
  3. Develop the competency of project personnel, with training and mentoring
  4. Multiproject management, including program and portfolio management, coordination and allocation of resources between projects
  5. Strategic management, including participation in strategic planning and benefits management
  6. Organizational learning, including the management of lessons learned, audits, and monitoring of PMO performance
  7. Management of customer interfaces
  8. Recruit, select, and evaluate project managers
  9. Execute specialized tasks for project managers (e.g. preparation of schedulers)
  For organizations using agile methods, these services can be delivered as follows:

1. Monitor and control project performance – Help teams track their velocity. Assist with tracking team and sponsor satisfaction ratings. Look out for and alert teams of dangerous velocity trends, check backlog size, and offer reviews of iteration and release plans.

2. Develop and implement standards – Provide templates for user stories, test cases, cumulative flow diagrams, etc. Provide agile PM tools, educate supporting groups on iterative development concepts.

3. Develop personnel with training and mentoring – Provide agile training courses, coaches, and mentors to help project mangers transition to agile projects and upgrade their skills. Send people to local agile events.

4. Multiproject management – Coordinate between agile teams, communicate between projects including items such as outlining progress, issues and retrospective findings. Help manage Release Trains at the program level and Investment Themes at the portfolio level using frameworks like the Scaled Agile Framework (SAFe).

5. Strategic management – Identify projects with opportunities for early ROI or competitive advantage.

6. Facilitate organizational learning – Gather project velocity profiles, capture, store and index retrospective findings. Include perceived PMO cost vs. value in project metrics.

7. Manage Stakeholders – Provide Product Owner training, guidance on acceptance testing and how to evaluate and give feedback on systems. Champion the importance of Subject Matter Experts (SMEs) to projects.

8. Recruit, select, and evaluate project managers – Develop guidelines for interviewing agile project managers.

9. Execute specialized tasks for project managers – train and provide retrospective facilitators, create agreements with agile project trouble shooters, provide mentors and coaches.

Understanding the role of a PMO and translating the goals into an agile setting helps create alignment rather than conflict between the groups. These items may sound a tall order for your average old-school PMO. However PMO’s are under pressure to remain current and demonstrate their value in a climate of fast moving projects, cost cutting and increased scrutiny.

In the September 2009 PMI Community Post magazine Jack Duggal published an article called “Teaching PMOs to DANCE” that dealt with the issue that many of today’s projects are moving quicker than PMO’s can respond. Many PMO’s struggle assisting projects that DANCE:

Dynamic and changing

Ambiguous and uncertain

Non-linear and unpredictable

Complex

Emergent nature of projects that causes instability

The agile community calls projects like these “a good fit for agile” and this is the synergy. When we can explain agile approaches are not just non-conformist, ill-planned projects, but instead a proven approach for these tricky new project types then a win-win is possible for both camps.

Jack Duggal also gave a presentation at the 2011 PMI Global Congress entitled “Reinventing the PMO which was quite agile manifesto like. Jack outlined a need for PMO’s to shift:

1. From Delivery of Projects to Benefits Realization and Business Value
No longer is delivery of on-time, on-budget projects considered successful. It is necessary but not enough. PMOs need to cultivate a mindset to shift to a benefits and outcomes focus and establish measures to ensure benefits realization and achievement of business value.

2. From Delivery to Adoption and Usability
Typically, PMOs are focused on improving execution capabilities. Projects are implemented well, but often the outputs and deliverables are not used or adopted. With a shift to an adoption and usability mindset, PMOs can promote and plan for adoption throughout the project lifecycle to ensure intended realization of projects’ benefits and value.

3. From Diffused and Disjointed Focus to Holistic and Balanced Adaptive Approach
Often PMOs are pulled to address the current pain or fix the problem of the day. This results in a diffused and disjointed PMO focus and limits the ability of the PMO to provide a balanced approach.

4. From Change Management to Change Leadership
Change management in the PMO realm has focused on configuration management and procedural changes. Evolving PMOs understand the need for organizational and behavioural change and get involved in change-readiness assessments and preparation. PMOs can play a key role in understanding, leveraging and leading change.

The “Next Generation PMO” as Duggal names it will have a mindset viewing the organization as a complex adaptive system. The PMO’s purpose becomes more focused on linking tactical & strategic help with business value. Success will be measured via benefits realization and business value rather than project delivery. All of which are very much aligned with agile concepts.

So, rather than PMO’s being unsupportive of agile, I have found most to be very co-operative when alignment with agile helps them address challenging projects, deliver value and stay current. Also as project managers experienced in agile take roles in the PMO I think this transition will accelerate. With some education and buy-in a good PMO can Provide Many Opportunities for agile teams.

(This article first appeared at projectManagement.com here)

Next PMI-ACP Exam Prep Class with Mike Griffiths

PMI-ACP Prep BookMy next PMI-ACP Exam Preparation course will be November 18, 19, 20 in Calgary, Alberta. The course will be capped to 15 people for better Q&A and will take place at historic Fort Calgary which is close to downtown on 9th Avenue and has free parking.

Since I am offering the class in my home town I have no travel costs and can offer the course for a discounted price of $1,290 for 3 days including lunches and snacks, my book, color printed workbook, sample exam questions, and USB stick of additional materials. (You can deduct another $60 if you already have a copy of my PMI-ACP Prep book).

The course has a 100% pass rate and uses Turning Technologies audience response technology. Following the course each participant receives a personalized follow-up study plan based on their sample question performances. For more details see the Course Outline.  To reserve your place or ask questions please contact Training@LeadingAnswers.com.


Planning Balance

Planning BalanceLife is all about balance, live too conservatively and you run the risk of missing out on life’s adventures and opportunities. Live too wildly and you run the risk of misfortune and regret, we have to walk a fine line guided by our personal view of where that correct boundary is.

Planning is similar; the adages of “Look before you leap” and “Cross that bridge when we come to it” speak to the differing views towards project planning. However, instead of being guided by some moral compass, we should be guided by the quality of our planning inputs and likelihood of changes.

To some people a mentality of “Cross that bridge when we come to it” strikes them as the irresponsible abandonment of project management rigor and fiscal responsibility trusted to them by project sponsors. Why would you not always do as much planning as possible before starting a project? Surely, that is only right and proper! Well, not if doing so would be harmful, it all depends on the quality of that input data. When the input data is good, we can reliably plan, when the input data is bad, or the project’s final destination is likely to change then we need to get better data and keep evolving the plans.

When aiming at a fixed target it is appropriate to aim, aim, and aim some more and then fire. In the project world this is akin to plan, plan, and plan some more and then execute. However, when trying to hit a moving target this approach is ineffective. Where do you aim? Where the target is right now, where you think it might be next, where you hope it might be at completion time? Instead a different approach is needed; something more like a guided missile that makes many mid-course adjustments to hit a moving target.

When we know our project requirements may change, or there is technological uncertainty, or market volatility from competing products, we need to equip the projects with the abilities to make multiple mid-course adjustments. Instead of plan, plan, plan we point the team in the right direction, get them started and give them the tools and authority to make these mid-course adjustments through build feedback cycles to hit that moving target.

Jim Highsmith says it best, there are times when “You cannot plan away uncertainty; you have to execute away uncertainty”. It is not really in the best interests of the sponsor to consume project time and budget trying to plan something with incomplete or erroneous data. It would be more prudent to get closer to the problem, try a few things and then come up with a better plan now we have more information.

Yet this idea of doing less upfront planning presents a large obstacle to many stakeholders because the words we often use to describe exploratory information gathering are poor. For a start we don’t often call it “exploratory information gathering” instead using phrases like “we will build a small portion”, “start coding”, or “do a spike”. To people not familiar with why we are doing this work it seems counter intuitive and rash. So, we can do ourselves a favour and use words like “more data gathering”, “proof of concepts” and “options exploration” instead of “development” to explain the goal of this work.

Another tool we can use to convince the skeptics that less upfront planning is sometimes better value is the planning-risk graphs developed by Barry Boehm. The first risk presented by Boehm is the obvious risk of not doing enough planning and running into problems of people not knowing what they are doing, duplicating work, and building poor solutions that need to be corrected.

Planning Balance 1

From the graph above, we can see that as more time is invested in planning, the risks due to inadequate plans reduce. While these risks are intuitive, there exists another set of risks that are less intuitive or obvious; the risks of doing too much upfront planning. 

Planning Balance 2

This second, red line denotes how the risks of creating very detailed, brittle plans that do not survive contact with reality increase as we spend more time planning. So too do the risks of delaying the project and getting a late Return On Investment (ROI) because the project spent too long in the planning phase.

Continue reading "Planning Balance" »


Agile For Oil and Gas - mixing lifecycle models

Considering Alternative LifecyclesIntroduction

This post is about Implementing agile at the organizational level across multiple technical domains. I was in Bogotá, Colombia recently working with an oil and gas company to introduce agile to their organization. They were not looking to improve their IT delivery, they were seeing if it could bring benefits to their whole business value stream. Since moving to Calgary 13 years ago I have worked with many oil and gas companies, they are the major employers here and the predominant industry. Lots of energy companies employ lean approaches to exploration, facilities creation and operations to maximize efficiencies and optimize the value stream.

Applying agile techniques to lean processes are a natural compliment and fit especially well with the unique problem solving and collaboration needed to undertake complex projects. Yet, oil and gas projects present a mixture of both these knowledge worker challenges that are a great fit for agile, and industrial engineering that requires traditional approaches. The real benefits come in knowing how to mesh these approaches together and provide some mental models to facilitate planning and problem solving. This is still an emerging field and I don’t think we have all the answers yet, which makes it challenging and rewarding. At the end of the post I outline some questions that I am trying to solve.

The Bigger Picture

Oil and gas development is a long value chain engaging many different groups with unique specializations. Like designing a new car, bringing it to market, producing it, selling and then sustaining it, the skills needed along the way are diverse and often conflicting. Oil and gas development includes the following disciplines:

  • Surveys – identifying areas with favourable geological conditions.
  • Surface Rights Negotiation – arranging for land access with land owners, environmental surveys, native and community outreach.
  • Exploratory Drilling – verifying the presence or absence of hydrocarbon reserves and quantifying the reserve.
  • Facilities – creating the infrastructure for oil or gas extraction, initial processing and transportation to market.
  • Operations – managing the safe extraction and operation of the well and associated facilities. Performing maintenance and projecting production declines and decommissioning work.

Oil Lifecycle

 Mixed Project Types

Some of these activities like the collaborative work of the G & G groups (Geologists and Geophysicists) are classic knowledge worker activities. Here specialists with subject matter expertise come together to share information and as a group and build consensus on the most likely areas for further exploration. No two regions are the same, no two geological formations are the same, and just like software teams use agile methods to collaborate on solving complex problems and gain consensus on the direction to move in, so too do G&G teams.

Further down the chain though, some pieces of work can be more traditional in nature. After determining an area to explore, the execution of a seismic survey might involve mobilizing a large workforce of several hundred people and scheduling constrained equipment. While this can be done in an iterative, prioritized manner, many of the benefits of short iterations, reviews and adaptation are diminished so a hybrid approach is preferable.

Agile Processes

Surface rights negotiation and exploratory drilling are very much expert driven, collaborative problem solving exercises. Starting the process with incomplete information and uncertainties is the norm. There comes a point where more planning can not remove the remaining uncertainty, instead execution must be used to provide data and remove uncertainty. Activities progress with the acknowledgement of ambiguity and proceed through stages of:

1) Embrace ambiguity – getting stakeholder agreement of areas of uncertainty

  • List areas of uncertainty
  • Discuss and agree known scope boundaries

2) Sense making – collaboratively forming consensus on exploratory work to undertake

  • Agree information gathering steps
  • Prioritize sense-making exploratory work

3) Iterate through cycles of Plan, Explore, Learn, Adapt – Learn by doing rather than speculate via planning

  • Plan – agree and assemble work plans, guidelines, objectives
  • Explore – undertake short period of exploratory work
  • Learn – collaboratively analyze findings and gather results
  • Adapt – retune upcoming work plans, incorporate learnings

4) Maximize value – once it is agreed that the “Next Best Dollar Spent” is elsewhere on the project AND the iterative learnings have been maximized, finish the experiments

  • Gain consensus that the exit criteria has been reached
  • Articulate findings, learnings and decisions

Agile Lifecycle

Continue reading "Agile For Oil and Gas - mixing lifecycle models" »


Agile for Fragmented, Part-time Teams

VolunteersI have a client who uses lean and agile-like processes outside of IT on research and development projects. They have been doing this for a number of years to help optimize constrained tools (drilling platforms) and resources (specialist inspectors). They like the agile concepts of prioritizing based on business value, working in short cycles, expediting rush jobs and frequently validating results and adaptation.

Recently they asked for help with some improvement initiatives that use multi-disciplinary teams to investigate and improve cross-department processes. These groups are staffed by senior engineers who volunteer to help make improvements, but the work is low priority and their time extremely limited. They are also geographically dispersed. Obviously that creates problems for agile practices like daily standups if team members get on average of two to four hours per week to contribute on an initiative.

At first I saw lots of challenges--agile promotes dedicated teams (co-location where possible), daily conversations with business stakeholders, etc. These groups had none of those things, yet three months later they were pleased with the successes they had. It seems when you are trying to coordinate the work effort of distributed, low-availability resources, the structure and visibility of tasks that agile brings is a great strength.

This somewhat counter-intuitive application makes more sense when you consider how such improvement committees traditionally function. Historically, similar work groups had faltered and failed to deliver benefits. The company was mature enough to look for inter-departmental improvement opportunities, but because it was no one’s full-time job (and they spanned departmental jurisdictions), work started but then failed.

Continue reading "Agile for Fragmented, Part-time Teams" »


An Antidote to Velocity Obsession

Agile velocityGetting things done is great; to get things done is why we start things in the first place and why we follow through even when presented with obstacles and setbacks. We do things because they will (hopefully) bring us to some better state. So getting these things done quickly is good because we arrive at this better state sooner.  We track our rate of development (velocity) as a useful measure of progress and also as a leading indicator towards when we should be done. However focussing too much on velocity is dangerous; it leads to myopic mindsets and even moronic behaviour.

Yes, velocity is good, but not at the expense of quality, good-will, or noticing subtle changes in direction. At the Agile 2012 Conference Jim Highsmith and Pat Reed hosted a session called “Velocity is Killing Agility” which examined how velocity (which should be as much a measure of team capacity as it is a measure of their output) is being misused. When organizations overly publicize and analyze velocity, misguided attempts to “Go Faster” lead to gaming velocity scores and not project team improvements.

A Measurement Parallel

For the last 6 months I have been using Strava.com to track my running and biking exercise. It is a social web site for tracking and sharing workout performance data that creates maps, leader boards of hills climbed, point-to-point fastest times, etc. Using your phone or GPS device while out running or riding your performance is automatically recorded and then uploaded and compared to everyone else that has ever covered the same route. Individual rides and runs become virtual races against people you have never met. After posting the fastest time for a segment Strava will send you emails such as “Uh Oh, <fast guy’s name> just beat your record on Heartbreak Hill, go out there and get it back!” It can all get pretty competitive and silly if taken too far.

I have found Strava to be a fun, addictive work-out analysis tool that has led to a few special outings just to retake some records back and generally push harder to beat my own previous times. I have also met a few new people who run and bike locally and found some new trails by looking at the maps of where people train.  The trouble with obsessing on getting the fastest times for segments is that it can drive stupid, myopic behaviour. Stories of people barrelling down trails on mountain bikes at crazy speeds yelling “Strava, get out the way!” at people are getting more common.” Similarly, if you can’t ride the last technical descent on “Coal Chutes Drop” – then just throw your phone over the finish line and you should get a better time!”

Continue reading "An Antidote to Velocity Obsession" »


PMI-ACP Exam Prep Class with Mike Griffiths

PMI-ACP Prep BookMy PMI-ACP Exam Preparation course will be April 15, 16, 17 in Calgary, Alberta. The course will be capped to 15 people for better Q&A and will take place at Fort Calgary which is close to downtown on 9th Avenue and has free parking.

Since I am offering the class in my home town I have no travel costs and can offer the course for a discounted price of $1,290 for 3 days including lunches and snacks, my book, color printed workbook, sample exam questions, and USB stick of additional materials. (You can deduct another $60 if you already have a copy of my PMI-ACP Prep book). To reserve your place or questions please contact Training@LeadingAnswers.com.

Continue reading to see further details from the Course Outline

Continue reading "PMI-ACP Exam Prep Class with Mike Griffiths" »


How Will Agile Be Remembered?

RememberIn the future how will agile methods be remembered by the project management community?  It seems history has a way of distorting the facts and simplifying concepts out of context. Here are a few examples:

1)    In the original Waterfall Software Development Process paper written by Winston Royce in 1970, after presenting the lifecycle diagram on page two, the author states “I believe in this concept, but the implementation described above is risky and invites failure”. Royce then spends the remaining nine pages outlining feedback loops and “Do It Twice” recommendations since there would be things missed in the first pass through. Read in its entirety, it outlines a fairly robust, risk tolerant approach to building systems that features multiple iterations and opportunities for learning and adaptation.

Yet, waterfall is thought by many to be a single pass lifecycle with all the associated problems. It is as if the project management community latched onto the lifecycle diagram depicted on page two and chose to ignore all the more difficult to implement yet critical steps described in pages 2-11. Read the original Waterfall paper here.

 

2)    Henry Gantt’s project management research and work actually focussed on retrospectives, diagnostics and optimizing work flow. Yet people remember him for the Gantt chart. The funny thing is that he did not even invent what we call the Gantt chart today; that was Joseph Priestley 100 years earlier.

Gantt’s charts were far more complex diagrams that were created after the work was completed and then used to identify waste and improve the process. While he started with scientific management of Fredric Taylor, his research went far beyond charting and optimizing labor. He was a harsh critic of ineffective management and promoted many Lean and Theory of Constraint like values such as “Increased production not through speeding up workmen but by removing the obstacles which prevent them from doing their work”, “Reduced costs, because of the elimination of idleness and waste as well as improvements in process”, “Men interested in their work not only because of the wages but because they have an opportunity to increase their knowledge and improve their skills.

 We often characterize Gantt with tracking charts, but that’s a faulty summary of a talented systems thinker; for more information on Henry Gantt, his real charts and work see Henry L Gantt 1861-1919 Debunking the Myths.

 

3)     The Manhattan project is often attributed as the origin of modern project management and phase gated approaches, however it actually pursued concurrent development. The Manhattan project to develop a nuclear bomb in the 1940s, certainly displayed the modern project management principles of organization and planning, but also high rates of trial-and-error and multiple parallel streams attempting to solve the same problem.

There was just so much uncertainty surrounding how to create a bomb, knowledge was theoretical and incomplete. The project manager, Leslie Groves, said: “The whole endeavour was founded on possibilities rather than probabilities. Of theory there was a great deal, of proven knowledge, not much. There was simply no ready solution to the problem we faced.” So, Groves and his steering committee decided to explore and implement different solutions in parallel. This approach (well multiple approaches) and willingness to modify and add solutions mid-course, led to technical breakthroughs that had been thought impossible by most three years before.

This was 30 years prior to Toyota’s “Set based engineering” but very similar in its pursuit of multiple parallel approaches. Yet today we most often hear of the Manhattan project as the birth of the phase gate approach, this is too bad, they did so much more.

 

4)     Lastly, the Polaris project that was attributed as the origin of Critical Path Method (CPM) and PERT was actually about gaining First-To-Market intellectual property share.  The Polaris project developed the first submarine-launched ballistic missile (SLBM) carrying nuclear warheads. These offensive weapons, almost impossible to track and attack, became a key element of nuclear deterrence.

The Polaris project is today credited with developing the “scientific approach to project management” with the first large scale application of computerized planning techniques, particularly CPM and PERT. A big part of the project was about “getting a share of the ballistic missile pie” away from the newly formed US Air Force that was receiving most of the Pentogon’s money. Admiral Burke astutely believed that “The first service that demonstrates a capability for this is very likely to continue the project and others may very well drop out”. The result was a clear prioritization of schedule over cost and specification; and a willingness to experiment and change specifications over the course of the project.

Trial and error led to two deployed tests in the early 1960’s and PERT served “…less for improving project control than for offering technological pizzazz that was valuable in selling the project. (Since) The image of efficiency helped the project. It mattered not whether parts of the system functioned or even existed, it mattered only that certain people for a certain period of time believed they did.” For more information on the fascinating truth of the concurrent development, experimentation, iteration, and adaptation that really underpinned the Manhattan and Polaris projects see Lost Roots: How Project Management Settled on the Phased Approach (and lost its ability to lead change in modern enterprises).

 

So, given waterfall was iterative, Gantt focused more on the theory of constraints not Gantt charts, the Manhattan project was Lean not Phase Gated, and the Polaris project was about rapidly gaining mindshare through iteration, I don’t really hold out much hope for agile methods to be remembered accurately in the future.

The glass half-full view of these history lessons shows that smart, resourceful people have been tackling complex project problems for centuries and our ideas such as lean-startup, Kanban, behaviour driven development, etc are likely not new.

The glass half-empty view is that agile methods will be erroneously summarized to tangential concepts,   such as “individuals without tools”, or “leave no documentation”. However, smart people will continue to be successful in managing challenging, audacious projects and terms are really just labels that matter less than the methods they describe or results they enable.

Maybe we have better collective knowledge these days and we will not repeat the same erroneous summarization and labeling of take away ideas. Lenfle and Loch, the authors of the “Lost Roots…” paper, assert that the loss of trial-and-error and strategy-making focus from popular project management, that was clearly present on these early projects, restricts the usefulness of project management today. Agile and lean approaches rediscovered this science and are attempting to merge it back into mainstream project management, but are up against a generation of resistance from those who were taught projects can plan out variability.

From an evolutionary perspective it is an encouraging sign that techniques that were lost through poor reporting have re-emerged elsewhere to exploit project environments that have high levels of uncertainty. Regardless of their names or origins, let’s hope they persist and get incorporated in mainstream project management, not to be lost again.

This article first appeared in ProjectMangement.com here. Bio: Mike Griffiths is a project manager experienced in traditional and agile methods who reads about project management much too much - you really don’t want to get stuck with him at a party!


Project Zone Congress Discount Code

Project Zone CongressThe Project Zone Congress will be taking place in Frankfurt, March 18-19. I attended the Project Zone Congress last year and was impressed by the quality of sessions and access to speakers for Q & A. This year’s conference is set to repeat the format and has some great speakers including Jurgen Appelo author of “Management 3.0: Leading Agile Developers, Developing Agile Leaders”. I love this title and wish I’d come up with it myself!

Readers of LeadingAnswers can receive a 10% discount from the conference by using the code “PZ2012_MEDIA03B869C8” when they register. It promises to be a high caliber conference with sessions on practical agile, the PMO and agile, strategy and leadership, see the schedule for full details.


Autonomy and Empowerment from an Unlikely Source

Agile PRINCE2It is well known that teams work best when they are empowered to self-direct and given freedom to self-organize. Yet striking the balance between providing this autonomy with responsible project oversight to ensure things do not go off track can be a tricky proposition. We want to create empowered teams, but we also need to know if the project is going awry and when to intervene. Unlikely as it sounds, but a great source for creating empowered team environments can be found in the prescriptive process of PRINCE2.

Edwards Deming, a major inspiration for Toyota’s lean approach, said there were two classic mistakes a manager can make. The first is intervening when common cause variation occurs. Common cause variation is the natural variance we see in process. For example some three day tasks will take four days to complete and this is just the way things are – common cause variation, managers need to accept the odd instance of this. The second classic manager mistake is not intervening in special cause variation, which is variation that is new, unanticipated, emergent or previously neglected. For example if project scope changes significantly (new and unanticipated) or velocity trends indicate the project will not get done within schedule (emergent).

So what we really want is a protective bubble for the team that insulates them from micro-management and outside interference – like a giant hamster ball, and also some guard rails and an occasional guiding hand to keep the giant hamster ball on track towards the project goals. I realize that picturing high-performing teams as hamster balls sells them short in terms of their intelligence, insight, commitment and dedication, but it fits with my guide rails metaphor. I was going to use the analogy of a state or province governed by its own local laws, but overseen by a government or federal body. It can self manage for most things, but not revolt, declare war on outside groups, or change direction. However my time living in Canada has taught me this metaphor is as likely to upset just as many people so let’s leave it open – a hamster ball run by the hamsters or a state/province governed locally, you choose - to many people they are not that different.

 As project managers we need to establish the boundaries for our team’s independence within which we have control over how we operate (definitions of common cause variation) and the mechanisms for detecting going off track (indicators of special cause variation).  This is where a concept from PRINCE2 can help. When starting a PRINCE2 project we establish Project Tolerances and Exception Processes. These set the boundaries within which the project manager / team can control project variation and what circumstances trigger an exception and escalation to a steering committee or project board.

Tolerances are established at the beginning of the project, agreed with project stakeholders and written into the project charter. They can be created for a variety of metrics such as time, budget, scope, risk, quality and represented as a simple range such as the budget tolerance as shown below:

  Basic Spend Tolerance

There are three components to the Tolerance / Exception process: 

  1. The Tolerance Range – the acceptable range within which the project manager (and team) get to operate without outside intervention.
  2. An Exception – a breach of tolerance (exit from a tolerance range) that triggers the escalation process.
  3. The Escalation Process – an agreed process that describes who will be contacted and what actions will be taken should an exception (breach of tolerance) occur.

In the figure below we can see that the blue spend line has exceeded the Projected Budget +10% upper tolerance range and so an exception is raised as per the escalation process for this measure.

Basic Spend Tolerance with Actuals


Tolerances can be also be more subjective such as a sponsor confidence score and tracked, say, monthly or bi-weekly.

Sponsor Tolerance

For an agile project, all this talk of documentation in a project charter can sound like more procedural overhead than we want to get into. Plus, scope may not be fully defined and so a more emergent process may be suitable for an uncertain project.  Yet we can take the tolerance idea and recast it in a lighter weight version, with appropriate metrics for an agile setting.

While there may be a less formal charter, most projects get launched with some approving document or discussion. Whether this is a project vision document or a kick-off meeting, this is the time to establish the team’s autonomous environment. Then, providing the project is on track (velocity and spend are OK, demo’s are showing progress, business is happy with quality and engagement) the team is empowered to self-organize provided no tolerances are breached or forecast to be breached.

Velocity Tolerance

By discussing the bounds of self-governance and describing what would trigger an exception stakeholders are more likely to let the team self-manage safe in the knowledge that provisions for being alerted are in place. The process of discussing tolerances and agreeing the escalation process allows teams to gain autonomy which improves morale, increases performance, and creates a virtuous cycle. As opposed to suspicious oversight that micro manages, leading to demotivated teams, and a self-fulfilling prophecy of skepticism.

Times of issue escalation are not the best moments to establish resolution processes, since people are concerned and emotional. Like having an evacuation plan for a building, if an event occurs when you need to use it, you want it already established rather than having to make it up during a real fire. The same goes for projects, it is much better to have an escalation process in place and then just execute it “We said we would convene a committee meeting if average velocity indicated we would not get all the “Must Have” work done with remaining funds. This is where the current projections show us and the options we have are… ”. This is preferable to having to invent some new process in the midst of a project issue.

Agile tolerances can be created around most observable measures that the project community cares about. They can be internally facing such as defect cycle time, that might trigger some special retrospective focus.

  Cycle Time Tolerance

Or externally facing such as User Satisfaction that could trigger a steering committee meeting..

User SatisfactionTolerance

The real point is that borrowing a process such as Tolerances, Exceptions and Escalations from PRINCE2 actually creates more freedom for teams to operate. Agile teams spend a lot of effort agreeing on a common definition of “Done”, by spending a little time to build a common understanding of “Concerned” we can all go faster knowing consensus on the definition and resolution process is in place.

Of course it is no silver bullet; on PRINCE2 projects we sometimes call the tolerances how much rope we give the project manager. Too much and they can hang themselves, too little and they are always coming back with approvals for minor adjustments. So, like everything it has to be applied intelligently, yet it can be a useful tool to have in your toolbox when starting up a project and looking to strike that balance between buffering stakeholders from common cause variation and alerting them to special cause variation. Autonomy creates freedom for the team to perform, while tolerances provide assurances to concerned parties who might otherwise be tempted to interfere too much.

(This post first appeared on www.ProjectManagement.com here)


Go Talk To Your Stakeholders

P4As a PM, what is the most effective thing you can do for your project in the next hour? (After finishing this article, of course!) I would suggest speaking to your project team members and business representatives about where their concerns lie and what they believe the biggest risks for the project are. The reason being that while tarting up a WBS or re-leveling a project plan might be familiar and comfortable (where you are a master of your own domain), it really amounts to nothing if your project is heading for trouble. Like rearranging deck chairs when you should be looking for icebergs, there are better uses of your time.

The frequency and magnitude of IT project failures are so prevalent and epic that people can appear in denial of their ability to influence, or “in acceptance” that a certain percentage of projects just go south. Does it need to be that way? If we spent more time asking people where stuff could go wrong rather than making ever more polished models of flawed project plans, could we change the statistics (even a little bit)?

According to research by Roger Sessions of ObjectWatch, 66 percent of projects are classified as “at risk” of failure or severe shortcomings. Of these 66 percent, between 50 and 80 percent of these projects will fail. So, if 66 percent of projects are at risk, let’s say 65 percent of these projects will fail; that’s .66 x .66, meaning 43 percent of projects fail. (Despite the grim projection, these numbers are actually slightly better than the Standish Chaos report findings). What would happen if we could prevent just, say, 5 percent of those from failing?

The impacts would be huge, because the amount of money spent on IT projects now is truly monumental. Of all these failing projects, there must be many that flirt on the edge of success versus failure--wobbling between being able to be saved and past the point of no return. These are my targets--not the doomed-from-the-start death marches to oblivion but the appropriately staffed, well-intentioned projects that just don’t quite make it. I bet there was a point in the path to failure when some more dialogue around risks and issues could have provided the opportunity to take corrective action.

The trouble is that we don’t know if we are on an ultimately successful or unsuccessful project until its path may be irreversible. So we need to be acting as if we could be heading for trouble at regular intervals. We should also examine the economics behind this suggestion to change PM behavior. How much is it really worth to maybe sway the outcome of just 5 percent of the projects that are headed to failure?

According to The New York Times, industrialized countries spend 6.4 percent of the GDP on IT projects. Of that, 57 percent typically goes to hardware and communication costs and 43 percent to software development. Of these, 66 percent are classed as “at risk” and 65 percent of them ultimately fail. The cost of failed projects is two-fold: There is the direct project cost, but also a series of related indirect costs. These include the cost of replacing the failed system, the disruption costs to the business, lost revenue due to the failed system, the disruption costs to the business, lost opportunity costs, lost market share and so on.

An investigation into a failed Internal Revenue System project showed a 9.6:1 ration of indirect costs to direct project costs. For our purposes, we will use a more modest ratio of 7.5:1. Let’s see how these figure pan out:

IT Failure Costs

So it turns out that the failing SW projects cost the world about $6 trillion dollars annually, and over $1.3 trillion in the United States alone. That’s a chunk of change, and saving just the 5 percent of projects wobbling on the edge of failure in the States would amount to $1,336B x 0.05 = $66.8B (or $1.28B per week).

How do we do it? Well, socializing the problem is a start. Let’s talk about project risks more often and raise them from the clinical world of reviews and audits up to the more human, approachable world of predictions and wagers. Ask team members to predict why the project may fail or get stuck. Ask our sponsors where they think the biggest obstacles lie. Follow up with “How do we avoid that?” and “What would have to happen to prevent that?” type questions, and follow through on the recommendations.

Just the act of discussing these issues can influence behavior. Armed with knowledge of where the really large icebergs are, people tend to steer and behave differently. To reiterate, we are not trying to prevent all project failures; just keep an extra 5 percent on track through frequent, honest dialog about the issues and a broader stakeholder awareness of the major project risks is a great way to start. So what are you waiting for? 

(I wrote this article first for Gantthead, here )

 


Collaborative Games for Risk Management - Part 2

Team ContributionsThis is the last post in a series on agile risk management. The first looked at the opportunities agile methods offer for proactive risk management, while the second examined the benefits of engaging the whole team in risk management through collaborative games. The last instalment walked through the first three games covering:

1. Risk management planning
2. Risk Identification
3. Qualitative Risk Analysis

This month we look at the final three sets of collaborative team activities that cover:

4. Quantitative Risk Analysis
5. Risk Response Planning (and Doing!)
6. Monitoring and Controlling Risks

The exercises we will examine are

  • Today’s Forecast -- Quantitative Risk Analysis
    • Dragons’ Den -- next best dollar spent
    • Battle Bots -- simulations
  • Backlog Injector -- Plan Risk Responses
    • Junction Function -- choose the risk response path
    • Dollar Balance -- Risk/Opportunity EVM to ROI comparison
    • Report Card -- Customer/Product owner engagement
    • Inoculator -- inject risk avoidance/mitigation and opportunity stories into backlog
  • Risk Radar -- Monitoring and Controlling Risks
    • Risk Burn Down Graphs -- Tracking and monitoring
    • Risk Retrospectives -- Evaluating the effectiveness of the risk management plan
    • Rinse and Repeat -- Updating risk management artifacts, revisiting process

Continue reading "Collaborative Games for Risk Management - Part 2" »


Collaborative Games for Risk Management

Team_solutionsThis is the third part in a series on agile risk management; Part 1 looked at the opportunities agile methods offer for proactive risk management, while Part 2 examined the benefits of engaging the whole team in risk management through collaborative games and cautioned us about groupthink. This article walks through those games and explains how to engage a team in the first three of the six risk management steps.

The PMI risk management lifecycle comprises of:

  1. Plan Risk Management
  2. Identify Risks
  3. Perform Qualitative Risk Analysis
  4. Perform Quantitative Risk Analysis
  5. Plan Risk Responses
  6. Control Risks

These phases can be addressed collaboratively via the following team exercises:

  • Plan Your Trip (Plan Risk Management)
    • 4Cs: Consider the Costs, Consequences, Context and Choices
    • Are we buying a Coffee, Couch, Car or a Condo? How much rigor is appropriate and what is the best approach?
    • Deposits and Bank Fees – understanding features and risks
  • Find Friends and Foes (Risk and Opportunity Identification)
    • Doomsday clock
    • Karma-day
    • Other risk identification forms (risk profiles, project risk lists, retrospectives, user story analysis, Waltzing with Bears - Top 5-10 for software)
  • Post Your Ad (Qualitative Risk Analysis)
    • Investors and Help Wanted – classification and visualization of opportunities and risks
    • Tug of War – project categorization
  • Today’s Forecast (Quantitative Risk Analysis)
    • Dragons Den – next best dollar spent
    • Battle Bots – simulations
  • Backlog Injector (Plan Risk Responses)
    • Junction Function – choose the risk response path
    • Dollar Balance – risk/opportunity EVM to ROI comparison
    • Report Card – customer/product owner engagement
    • Inoculator – inject risk avoidance/mitigation and opportunity stories into backlog
  • Risk Radar (Monitor and Control Risks)
    • Risk Burn Down Graphs – tracking and monitoring
    • Risk Retrospectives – evaluating the effectiveness of the risk management plan
    • Rinse and Repeat – updating risk management artifacts, revisiting process

We will walk through the first three steps in this article and then the last three steps next month:

1. Plan Your Trip (Plan Risk Management)
This phase is about deciding and defining how to conduct risk management activities for the project. We want to tailor the process to ensure that the degree, type and visibility of risk management is commensurate with both the risks and the importance of the project to the organization. So we do not use a sledgehammer to crack a nut, or undertake a risky, critical endeavor with an inadequate process.

The other goal we have for this phase is to teach some risk basics to the team since they may not be familiar with the concepts or terminology. The name of the first exercise (“Plan your trip”) speaks to the goal of determining the appropriate level of rigor. Most people can associate with planning for a walk or hike, and this is the context we use for the activity called the 4Cs. Early in any collaborative workshop, I like to get people working. If you let them spectate for too long some will retreat into “observer” rather than “participator” mode.

Working individually (again to encourage active engagement, and avoid groupthink), ask the team to consider what they would pack for a two-mile hike in the country on a warm day. Give them a couple of minutes to create lists on Post-it notes and review their responses as a group. Some will suggest taking nothing, others just a bottle of water, rain jackets, bear spray (I live near the Rocky Mountains in Canada) and all sorts of other things. We then review the pros and cons of these items. They are useful if you need them, but a burden to carry. We then repeat the exercise changing some parameters such as making it a 10-mile hike or a multi-day trip in the mountains during winter. Now the lists get longer as people prepare for more eventualities.

For each situation, we review the 4Cs: the Costs, Consequences, Context and Choices. What we bring (and how we prepare for risk management) varies based on the cost of bringing/using it, the consequence of not having it (rain coat: get wet; warm jacket : cold/hypothermia). We also examine the context we are talking about: preparations for elite ultra-marathoners who are hardy, capable and resourceful, or a kids’ group that needs more protection. Finally, the choices we make should be an informed balance of cost versus consequence in the frame of the context.

We need to understand these same elements in planning our risk management approach, too. Is this project domain our core competency? What are the costs and consequences of project risks occurring? What is our company’s risk tolerance and preferred risk management approach? Make sure people understand the environment.

Another tool to relate the need to tailor the process appropriately is to ask the team to consider the decision rigor they put into their purchases. The way we consider buying a coffee ($2), a couch ($2,000), a car ($20,000) or a condo ($200,000) varies as the figures involved escalate. For a coffee, we probably just find something close, maybe at our favorite store. For a couch, people will shop around and likely buy the one they like the best without much further research. When it gets up to car territory, safety, economy and resale factors are routinely examined. For a condo purchase, the stakes are so high that most people engage professional help from home inspectors and condo document review companies. We need to do the same for our projects, asking what is appropriate for the endeavor.

Finally, if the team is new to risk management then a discussion on the tradeoff between business value and risks might be necessary. We undertake projects usually for the potential upside (or for compliance projects to avoid the downside)--we are hoping for business benefits. Agile projects use business value as an input into work prioritization; we do the high-value items first. We want to deliver business value, and getting business value out of a project is like receiving deposits into our bank account--we want them as often as possible, and preferably as large as possible. Given the uncertainty in the world, we want the biggest gains as soon as possible before anything changes that may threaten future deposits.

In this bank analogy, risks are like withdrawals or bank fees--should they occur, they set the project back, take away resources from delivering business value and threaten the delivery of future value. So to get the most out of a project we need to maximize business value while avoiding or reducing risks. These exercises and discussions aim to get the team thinking about the appropriate level of risk management for the project and gain consensus and support for the strategy that is agreed upon. Without this shared understanding of “Why?” we will not get people invested in the process.

2. Find Friends and Foes (Risk and Opportunity Identification)
The next step in the process is to identify potential risks and opportunities. Opportunities are the “good” risks or fortuitous events that have a positive impact should they occur. We want to avoid risks and exploit opportunities. The IEEE have some good risk profile models for software projects. They were created by collecting risk information from thousands of completed software projects, then categorizing and ranking the common ones. These models can be used in a group setting or, as I prefer, used as the inspiration for a collaborative game. The “Doomsday Clock” exercise is based on a risk profile tool I have written about previously.

Using a clock view pre-drawn on a white board or flip chart, we ask team members to think of project risks associated with each of the topics represented by an hour line on the clock--12 in total. (For a detailed description of the types of risks within each category we would be asking the team to identify, see the spreadsheet attached to the risk profile article.)

This is the doomsday part: Wwe encourage the team members to think of and record as many risks as they can about that topic. We work topic by topic, but if thinking of risks triggers ideas in other areas as we progress, it is not unusual to get risks being added to previously discussed risk lines. Again, I prefer having people working individually for coming up with ideas. Then we put them all on the wall and consolidate and remove duplicates as a group, which also sometimes identifies new risks.

This process takes a while; spending just five minutes on each topic requires an hour to go through them. Discourage people’s tendencies to want to score, rank and solve the risks. This is risk identification--we will have plenty of time to process them later.

Doomsday Clock

Continue reading "Collaborative Games for Risk Management" »


Free PMI-ACP Webinar

PMI-ACP HandbookPlease join me on Wednesday May 2nd for a free webinar on “PMI-ACP: Adopting Agile into the PMP World.” This is part of Rally Software’s webinar series and we already have >2,000 people signed up. The session runs on Wednesday May 2nd at 7am (PT) / 10am (ET) and then again at 1pm (PT) / 4pm (ET) You can sign up here

In the webinar I will be talking to Juie Chikering about the exam’s content, who it is aimed at, it’s positioning in the industry, and how it has changed since the pilot last year, amongst other things. There will be interactive poles and questions from the audience, so it should be an interactive and informative event.

I will be presenting the webinar from the RallyOn Conference in Boulder, CO where I am also speaking about agile PMOs and on a panel with Dean Leffingwell, Johanna Rothman, and Alan Shalloway about the future of agile. I am really looking forward to it and also spending some more time in Boulder which I especially enjoy.


PMI-ACP Book Discount

PMI-ACP Exam Prep CoverI picked up a copy of my PMI-ACPSM Exam Prep book on a visit to RMC Project Management over the weekend. It was good to see it printed up for the first time, and with all the exercises and 120 sample exam questions, it was thicker than I expected at over 350 full-size pages.

The extra weight also comes from the case studies of agile projects I have worked on over the years and the additional materials I included to link the exam topics together. These items that are not in the exam are clearly marked so you can skip over them if you want. However, I am sure some people will find they add value by making the ideas more real. These additional materials also supply useful information to allow readers to fully understand the topics, rather than just memorize the information for the exam.

I am very grateful to the staff at RMC for pulling together my thoughts and ideas into this book, and for the people who reviewed it. Alistair Cockburn and Dennis Stevens were particularly helpful, and after reviewing it, they wrote the following quotes for the cover:


“As one of the authors of the Agile Manifesto, I am delighted to see this book by Mike Griffiths. It is great that such an exam guide was prepared by someone with a deep understanding of both project management and Agile development. Personally, I hope that everyone reads this book, not just to pass the PMI-ACP exam, but to learn Agile development safely and effectively!”

– Dr. Alistair Cockburn, Manifesto for Agile Software Development Co-Author, International Consortium for Agile Co-Founder, and Current Member of the PMI-ACP Steering Committee.


“This is a VERY enjoyable book to read, due to Mike's firm grasp of the underlying concepts of Agile, and his articulate and entertaining writing style. My favorite part is the fact that it is organized into a framework that helps all of the Agile concepts hang together, so they will be easier to recall when taking the PMI-ACP exam.

But Mike's book is more than just the best PMI-ACP prep book out there. It is also the best consolidated source of Agile knowledge, tools, and techniques available today. Even if you are not planning on sitting for the PMI-ACP exam in the near future you need to buy this book, read it, and keep it as a reference for how to responsibly be Agile!”

Dennis Stevens, PMI-ACP Steering Committee Member, PMI Agile Community of Practice Council Leader, and Partner at Leading Agile.


Thanks to you both, working with you over the years has been a blast. I would also like to thank the visitors of my blog here, too, for reading my posts and submitting insightful comments that kept me motivated to write. RMC has provided me a limited time promotion code that gives readers a further $10 off their currently discounted price for the book. If you follow this link and enter promo codeXTENMGBD”, you can get the additional $10 discount up until May 18th 2012. This is a 25% reduction on the retail price.


Unlikely Origins

Agile ExceptionForbes ran a nice article a couple of weeks ago on how agile is the next big thing for management, but its unlikely origin in the software industry may hamper its adoption. The article provided some nice analogies:

1)    When the British government, in 1714, offered a prize for determining longitude at sea, of £20,000 (£3M in today’s money), a Yorkshire carpenter called John Harrison eventually solved it, but the scientific community refused to believe that a carpenter could have solved the problem that had thwarted the best scientific minds. In 1773, when John was 80 years old, he received an award of £8,750 but not the actual prize. A Yorkshire carpenter was the wrong person to have solved the problem.

2)    In 1865, Gregor Mendel, an unknown professor created a theory about gene inheritance after studying pea plants. It answered inheritance issues that had stumped the finest scientific minds. The paper was ignored by the scientific community for the next 35 years until people eventually realized that Mendel had indeed come up with the solution. His theory later became known as Mendel’s Laws of Inheritance. His work had been ignored; a researcher on peas was the wrong person to have created the theory.

3)    In 1981, Barry Marshall, a pathologist in Perth, Australia, came up with a bizarre new theory that ulcers were caused by spiral bacteria. No one believed him so in 1984 he drank a batch of spiral bacteria and sure enough developed ulcers. Eventually in 2005 he received a Nobel prize for medicine for his work, but it took that long to be accepted. An unknown pathologist from Perth was the wrong person to have made the discovery.

So then we come to agile; for decades management had struggled to balance execution with innovation. How do we simultaneously get work done yet still drive improvements without one factor stifling the other? Now we know agile methods do a great job of balancing delivery with improvement.

Agile methods also provide a framework for sense-making and managing ambiguity when there are significant gaps in our understanding of requirements, approach, or technology. These uncertainties have a habit of stalling plan-driven approaches that struggle to reach escape velocity from the process of gathering requirements and planning. Agile methods instead choose to build what we know, evaluate, gain consensus on where to go next and iterate to a final solution.

The credibility problem we have is that software people, those weird IT geeks with poor communication skills are the wrong people to have proceduralized a complex communication and collaboration process. It should have been some management professors at the Harvard Business Review or Sloan School of Management at MIT. How can that IT crowd, who some believe have trouble making eye contact and describing an issue without resorting to techy speak, have figured out a way to collaborate and communicate on unique problems with unprecedented solutions?

Continue reading "Unlikely Origins" »


Agile Interruptions

By Mike Griffiths

Agile Communications“My team has stopped talking to me, and I like it!” This may sound like heresy since agile teams are centered on face-to-face conversation, but as with most sound-bites it is missing context and clarification. A more accurate description would be: “We are replacing some face-to-face conversations with other communication channels and this practice seems to improve flow.”

Like all good stories I have started in the middle, let’s back up and examine the full picture. “Flow” is the quiet and highly productive state of work when you are really “in the zone” and making real progress on a topic.

In the book “Flow: The Psychology of Optimal Experience” Mihaly Csikszentmihalyi explains what makes an experience genuinely satisfying and how people typically experience deep enjoyment, creativity, and a total involvement in their work when in this state of flow.  We experience flow when work is challenging enough to provide a reward of problem solving yet not too crazy difficult that it is frustrating. So, not too easy, and not too hard, but a perfect “Goldilocks” rating of “Just-Right.”


Task Difficulty

Shimon Edelman, a cognitive expert and professor of psychology at Cornell University, offers some insight in his book “The Happiness of Pursuit: What Neuroscience Can Teach Us About the Good Life.” He explains it this way: “Flow is the enjoyment derived from being engaged in an activity that is challenging, but not frustratingly so. Evolutionarily, we are selected for being good at certain kinds of things. You’re not challenged if you’re not tested, we get rewarded incredibly with this feeling of well-being and excitement.”

Enjoyment and Productivity are self-reinforcing factors that give rise to high performance.

Work Productivity and Enjoyment

The befits of flow on productivity are so significant Tom DeMarco and Anthony Lister in their book “Peopleware” recommend designating two hours a day as “Quiet time” with no meetings or interruptions. Programmers need sufficient quiet time to get into this productive mode, and as Alistair Cockburn observes, it takes only a minute or two of other conversation to disturb it.

This is the flow / communication paradox, on the one hand we want to get to a state of flow, on the other we want a collocated team environment with lots of high bandwidth, face-to-face communications to get questions answered quickly. There have been a few suggestions strike to balance . In the “XP Applied: Playing to Win” book Ken Auer suggest the “Caves and Common” idea. Caves are quiet rooms to work in, Common is the common work area where we learn via osmotic communication and get our questions answered quickly. People can go an work in the quiet “caves” when they need to focus and return to the common area to share and learn when they are done that high concentration task.

Why my team has stopped talking to me, is because they now use instant messaging. So instead of them coming over and asking a question mid way through my angry birds, status report, instead I get a little pop-up at the bottom right hand side of my monitor for me to reply to. The key difference is that this is not so interrupting as having someone physically come over. I can continue with my chain of thought, reach a convenient checkpoint and then type a reply.

Working this way flow seems to be less interrupted, it is no longer a cold reset of re-establishing where I was in my work and getting back into the groove, the interruption was less obtrusive and flow returns quicker. Perhaps because we decide the exact moment when to reply, allowing us to reach a better checkpoint/return point.

When team members who sit 6 feet away started sending me messages rather than talking to me I dismissed it as the poor communication skills of today’s younger workers, the product of text messaging generation, and generally a cop-out of having a meaningful conversation.

Now I realize that many quick questions are not worth the flow interruption penalty of a full face-to-face conversation. So items do however, if we think there is a problem, or need for a direction change then a full stop and discussion is exactly what is required, but for perhaps 5 times as many questions an electronic ping gets the answer without the interruption of flow.

I am not disputing the advantages of face-to-face communications, we will always benefit from the emotion and body language we lose electronically. However, given the value of flow and being in that productive zone, if we can keep that speed going for longer with less disruptive questioning, perhaps the overall business value delivered can go up with fewer face-to-face interruptions?

Likely this is very environment dependant, some projects will be constrained by their rate of learning and more face-to-face communications would help. However other projects, or perhaps the same project at a later phase, could be constrained by productive flow and better served by less intrusive Q&A. Balancing flow and feedback will always be dynamic.

What do you think, does technology help us here in balancing flow with being informed? How are you managing these competing demands? I would love to hear alternative solutions to this widespread issue.

(Note: This article first appeared on Gantthead.com here)


PMI-ACP Book Coverage

PMI-ACP BooksI finished my PMI-ACP Exam Preparation book a couple of weeks ago and now it is with the publishers for reviews and final edits. It turned out larger than expected, but I think better for the extra exercises and sample exam questions.

When designing the PMI-ACPSM exam, we needed to base the content outline on existing books and resources so that candidates would understand what the exam would test them on. When choosing the books, we went back and forth on our decisions of which books to include, since there are so many good resources available. And while we recommend that people learn as much as they can, we also had to recognize the need for keeping the exam content—and the preparation process for the exam—reasonable. In the end, we selected the following 11 books:

  1.    Agile Estimating and Planning, by Mike Cohn
  2.   Agile Project Management: Creating Innovative Products, Second Edition, by Jim Highsmith
  3.   Agile Project Management with Scrum, by Ken Schwaber
  4.   Agile Retrospectives: Making Good Teams Great, by Esther Derby and Diana Larsen
  5.   Agile Software Development: The Cooperative Game, Second Edition, by Alistair Cockburn
  6.   Becoming Agile: ...in an Imperfect World, by Greg Smith and Ahmed Sidky
  7.   Coaching Agile Teams, by Lyssa Adkins
  8.   Lean-Agile Software Development: Achieving Enterprise Agility, by Alan Shalloway, Guy Beaver, and James R. Trott
  9.   The Software Project Manager’s Bridge to Agility, by Michele Sliger and Stacia Broderick
  10.   The Art of Agile Development, by James Shore and Shane Warden
  11.   User Stories Applied: For Agile Software Development, by Mike Cohn

Reading all of these books takes some time, since the 11 books add up to more than 4,000 pages. The books also cover a lot more material than you need to know for the exam. From each book, we extracted the portions that best covered the exam content outline topics, and the exam questions were then targeted at those specific sections.

Continue reading "PMI-ACP Book Coverage" »


Timebox Alternatives

By Mike Griffiths

Agile WayThe Mayans may have had the first timeboxed project. They had a strict 2012 timebox cut off with little room for extension since the world would no longer exist. Although agile methods have been preaching the benefits of fixed timeboxed schedules since their creation, it still raises concerns with many stakeholders.

The triangles diagram from DSDM created in 1994 shows the shift from fixed Functionality (vary resources and time) to fixed time and cost (vary functionality).
 
Agile timebox 1

So, instead of fixing functionality (scope) via the signoff of a specification document and completing all of this functionality (hopefully within the time and budget specified), instead the resources and time are fixed and as much of the functionality as can be completed is done before the time and money runs out.

This sounds a bit like time and materials, but there is an understanding that the core functionality, the Must Haves, the Priority 1’s, or whatever you want to call them, will be delivered. In fact 80% of the outlined functionality should be delivered and it is the last 20% that is up for replacement with late breaking changes that could add even more value.

So, the best of both worlds then? All the important features and an opportunity to swap out low priority elements with things that might crop up as we go. However this is not how many stakeholders view it. Projects typically have three stakeholder groups: Sponsors who commission and fund projects, Users who, well, use them to do some work, and the Project Team who builds them. While at the 30,000 feet level all the these stakeholder groups want the same thing, a successful project, when we dig a little deeper other priorities emerge.

Agile success intersection
 

Continue reading "Timebox Alternatives" »