PMI Global Insights

A number of years ago I was asked by a client to help them procure and implement a COTS product - but I had to use Scrum to do it.

That being said, when I got there I was handed a 246-page RFP that a similar organization had issued for the same kind of procurement. That did not look very like it was very agile approach to me so I said ah, I won't be producing one of those!

So how did do we do it? Here are the three steps:

1. Figuring out why the business needed the COTS product

Step 1 was to figure out why the business though they needed the COTS product. To do that I introduced outcomes mapping (which is a variant of Benefits Mapping) to help them more clearly articulate why they were needing to do the project from a business perspective rather than from a technology perspective. The 246-page RFP document I was handed was mostly technology-focused which is why I felt we needed to avoid a similar trap.

As soon as we had the first draft of the outcomes map created we printed on a 3x4 foot sheet and put it on the wall in our war room for the project (see David Maynard's excellent post on how war rooms can help any project).

Having a visible map of the “why” enabled both the business and the IT teams to add details or ask questions using sticky notes anytime they walked by the map. We would then stand around the map as a team every day and review the content of the latest stickies to figure out where we needed to update our map with our now emerging understanding of the business problem we were solving. Once we agreed on what needed to be changed, we would update the map, reprint it and put the newly revised map back on the wall.

This created an opportunity for serendipity for both the business and IT as they would walk by and study the map. As they stood there looking at the map this often led to others stopping as well which of course led to them to talk about the map together. These ad-hoc conversations led to some of the most insightful additions to the map.

Over the period of about 8 weeks or so the big visible map of the why for the project led to the identification of:

• Four major new business process areas that had to be designed, developed and implemented that the business had not previously recognized.
• The fact that the intended COTS product was only one of five different tools that were actually needed and was only one of two in the business process area where it was to be used

As you build an outcomes map there are natural structures that emerge that help you categorize different parts of the map. As this picture emerges it also helps you identify what you need to do (projects/initiatives) satisfy the why you are doing it (the outcomes)

2. Figuring out what the product to be procured needed to do

I facilitated the business groups in identifying the required business capability areas that the product needed to address along with capability statements within each capability area as to what they needed the product to do.

This enabled them to rank each capability statement according to a scale of business importance (Very High, High, Medium, Low, Very Low). This took about 8 weeks or 4 Sprints. The business was solely responsible for these prioritizations of business importance.

We created a Business Service Canvas for this step which was a derivative of the Business Model Canvas. As with the outcomes map we printed the canvas on a 3x4 foot sheet and put it on the wall for the team to use stickies to capture their additions or questions. The Services on the canvas started with those that the Learning and Development group (the business group) already provided to the rest of the organization. It then morphed into those that it would need to provide in order to satisfy the business outcomes from step 1.

We then led the business team through a series of pair-wise comparisons of "buy-a-capability" for each of the statements in each priority level within each capability area as follows:

• Let’s say Capability area 1 had 4 capability statements ranked at Very High.
• We would have them compare the first two by asking if they only had $1 and could only buy one of them, would they chose one over the other or would they say I guess I don't have enough money.
• If they chose one over the other, then the losing statement would be changed to High from a Very High.
• If they could not choose one over the other, they would both stay at Very High.
• We did this for all capability statements for all priorities for all capability areas.

Once all of the capability statements were re-prioritized, we asked them to consider the Low and Very Low ones and whether they wanted us to include them in the RFP seeing as they had already said they were not all that important based on their assigned level of business importance.

After some discussion the business decided to remove them from the RFP. This allowed us to end up with an 8-page RFP document augmented by pre-populated spreadsheets with the capability statements organized by capability area. We provided room in the spreadsheets for the vendors to fill in their actual responses which had to refer to their own product documentation that supported their statements of product fit. The vendors were not allowed to submit bound or printed responses to the RFP.

Using the Business Service Canvas also helped the business identify the need for role re-evaluations based on newly realized skills gaps as well as missing roles within their organization.

This step took about another 4 Sprints to get through.

3. Run the Procurement

Now that we knew why we were doing the project and had a solid understanding of the what the COTS product needed to we were ready to run the procurement itself which meant:

• Issuing the RFP
• Evaluating vendor responses
• Running a boardroom demo for the vendors to show how their product satisfied the required business capabilities
• Selecting a winner

Vendor responses to the RFP were received after being out for 8 weeks. The entire response evaluations took less than a week which included the boardroom demos for the top-3 ranked vendors.

The boardroom demos also led to a switching of the initial number 1 and 2 ranked vendors which rarely happens in traditional procurements. Implementation of the COTS product took an additional six months.

(Note: while some some internal delays stretched the overall delivery timeline to 18 months it was within the original expected time which was also 18 months. Without these delays we would have finished about 4 months early)

Actual expenditure on the procured software was only about 2.5% of the original expectation of expenditure as we only evaluated those things that the client really needed – the business spent a mere $25,000 of the original $1 million originally allocated for the product.

The vendor selection process also considered the ability of the vendor to help with an incremental deployment and use agile practices for developing the required integration with other corporate systems within the business.

Use agile procurement practices means being willing to rethink the procurement process itself as well as the chosen vendor's ability to support agile practices in their product implementations.

Conclusion

Scrum, outcomes mapping and the Business Services Canvas, as well other practices we introduced allowed us to:

• Realize that the “project” was actually a program of projects not a single project as originally thought. In all there were six initiatives across four major business capability areas
• Guide the business team in defining their Minimally Viable Product Features for the COTS product which saved 97.5% of the original $1M budget
• Identify a define the new services they needed to stand-up within the Learning and Development group to satisfy the four business capability areas
• Identify, design, and develop all of the required Minimally Viable Business Processes.
• Identify the new roles can changes to existing roles that would be needed to support the new and existing services based on the new capability areas ad processes

The procurement itself took less time, cost considerably less than planned (only 2.5% of the budgeted $1M), used a far less complex procurement process, and achieved the right results for the business.

The project was completed within the original overall budgeted cost of $2.5M, within the same expected time-box of 18 months, yet delivered newly identified business processes, services, and additional tools (with the money saved in the procurement), none of which were part of the original project definition and scope.

Have you used Scrum in a procurement? I'd love to hear how it went.

(Originally posted on LinkedIn and in the The Agility Series Blog)

In the movie Office Space, the character Milton becomes so enamored with his 'red stapler,' that when he is deprived of his cherished possession, he follows through on his threat to “burn things” – which in this case was the office building where he worked.

For Milton he let his red stapler become synonymous with his self-worth as the only thing of value he had left after all of his job functions, and eventually his paycheck, were taken away from him.

I have often used the red stapler story and analogy when delivering agility training to describe those remnants of traditional management practice that many people want to hang onto - even when it is clear they are no longer relevant or useful, or that in many cases they are an impediment to their ability to fully embracing Agility principles and practices. At worse, our red staplers can be so destructive to a team that it can lead them to abandoning agility practices altogether.

For many project managers and PMO's, their red stapler can be their project management deliverables. While they may say they are doing Agile Project Management (I prefer Agile Project Leadership) or have created an Agile PMO, many of them in fact have a hard time letting go of traditional deliverables, planning techniques, practices such as status reporting, or metrics that don’t reflect or support agility thinking and delivery, to name a few.

I have worked with some teams who take a proactive approach to rooting out their red staplers. I have seen other teams who don’t understand the issue, and don’t see the destructive aspects of hanging on to them.

If you are going to truly make the transition to agility you need to figure out where your red staplers are hiding and root them out.

What do you think? Do you have your own “red stapler” which you are finding hard to let go of?

MEET ME IN SAN DIEGO NEAR THE PROJECTMANAGEMENT.COM BOOTH.

(First published on LinkedIn and in the The Agility Series Blog)

When we use the word agility these days it is usually prefaced by the words organizational or business. But are organizational or business agility the only two types of agility?

Before I answer that question I need to fill in a bit of the back story about why I asked myself that in the first place. Last year I was the lead author on a book called Agile Value Delivery: Beyond the Numbers which we were lucky enough to have endorsed by a co-author of The Manifesto for Agile Software Development. At the same time as I was leading the writing that one I was also acting as the mentor for the PRINCE2 Agile and I was working on creating an Agile for Executives and Leaders course - it was a bust six months!

As I was laying out the course I felt the need to take a different approach than simply writing yet another executive overview of Scrum or basic agile the way most have done (while there is value in those as well I wanted something a little different). Our book  had talked about Value agility and we also had a section on the implications of agility thinking on the rest of an organization with a particular emphasis on HR and Finance.

So as I started writing the course I began to think about the 'rest of the organization' part we had mentioned in our book. So that's where 8 of the 9 types came from, which I  introduced in the course.

The 9th type of agility came about while working with my friends at www.GreatWork.io and with our first wisdom council for our recent book on Organizational Agility where polled a group senior leaders on 4 continents on what they thought Organizational Agility really was. One of our council members, Claude Emond identified Learning Agility as a missing type so it was added to the list.

So, here are the 9 types of agility with a (still forming) definition for each type:

1. Organizational Agility - Organizational Agility is what you get if the other eight types of agility are present. While that statement is true, what is also true is that how we define our organization through mission, vision, values, and  principles statements determines the organization that we get. While Mission and vision are specific to each organization,  values and principles statements can be more universal. For example think the Manifesto for Agile Software Development is applicable in any organization that does software development. The manifesto’s values and principles statements are  not specific to any single organization. So is, we believe, with the values and  principles of an agile organizations—there are some statements that have a universal applicability to them.
2. Leadership Agility - will focus on helping leaders understand the differences between the traditional model and the one required to lead an agile organization in an ambiguous an uncertain world (will be tackled next)
3. Cultural Agility - focuses on the culture of our organization while recognizing current contexts such as the five generations in the work force, the importance of diversity, as well as our values and principles. This supports the ‘who’ aspect of  delivery as well as the environment we want to create for success. We will be adding a tool very soon to our learning portal that focuses on the creating high-performing teams in support of cultural agility.
4. Strategic Agility -focuses on ensuring we have unity in leadership and remain sensitive to emergent understanding as we execute against our strategic goals such that we can reallocate our people and resources as needed. This establishes the why of things. We have already released a companion guide for this one.
5. Value Agility - focuses on prioritizing and incrementally delivering value through individual product deliveries that are in line with an organization’s strategic objectives and key stakeholder needs. This establishes the what and when
6. Delivery Agility - focuses on making the right choices in each part of delivery to support the established priorities for value delivery. This establishes the how, who, and where
7. Business Agility - focuses on improving efficiency and effectiveness in current business operations. This serves to both validate the value that has been delivered and also identifies new opportunities for creating value
8. Client/Customer Agility - focuses on how we can create and maintain a shared understanding on the “why” question throughout delivery. It takes an outside-in view of the organization and why it does things - to satisfy customer needs
9. Learning Agility - focuses on the people in your an organization and adopts the perspective of hiring people who have a growth mindset over a fixed mindset which means hiring to behaviours versus only hiring to skill. Hiring the behaviours which support your values and principles is a leading indicator of how well people will mesh into your culture. As an organization is a reflection of its people, if you want an agile organization t

As The Agility Series is still being written (both literally and figuratively) it remains to be seen whether we will stop at the 9 types or not as we don't know what will emerge from the work ahead. It also remains to be seen what the exact definitions will be for each type - the above is just our starting point.

So what do you think? Are they other types of agility ?

MEET ME IN SAN DIEGO NEAR THE PROJECTMANAGEMENT.COM BOOTH.

(originally posted on LinkedIn and on The Agility Series Blog)

On a recent Sunday morning, and as I am apt to do on weekends while drinking my morning coffee, I spent the first hour or so wandering through Facebook, LinkedIn  and Twitter seeing what my connections have been up to over the past few days.  That morning I saw a post on Facebook by a old friend of mine on the definition of coddiwomple.

Ever had that moment where you see a description of something or you a come across a word that succinctly summarizes something for you?

Coddiwomple is one of those words for me. For those who have read my recent book on Organizational Agility or my Adaptive Strategy Framework Guide or my first book Agile Value Delivery: Beyond the Numbers, attended any of our webinars, read any of my previous posts, or is an member of my LinkedIn group know that I write a lot about uncertainty and the fact we live in a VUCA world.

Living in a VUCA world means that we cannot use the past to predict the future  which is a basic assumption behind most strategic planning exercises that try to lay out a vision for the next 3-5 years. Couple this with the fact that our window of opportunity is now often measured in months and not years, and that our windows of stability are now measured in weeks instead of months, leaders of every organizational size and in every sector are challenged more that ever to learn how to be adaptive. They need to learn to base their decision-making on what they and their people do next based on what know today they did not know last month or even last week.

Does that mean that strategy execution is now a crap-shoot?  No. What it does mean is that we can no longer assume that we can simply make a plan and work the plan. It  means leaders and their teams  need to do strategic iteration as opposed to strategic planning as I describe in my Adaptive Strategy Framework Guide.

Being able to prioritize what you and your teams do next means you need to have some sort of destination in mind, a vision of the future. This  enables you to move towards that destination, however vague it may be, in a purposeful manner.

By taking an adaptive approach to how you realize strategic goals and objectives also means that you may in fact end up at a slightly different destination that what you originally envisioned. And that's OK as it will be where you need to be, which is not necessarily where you intended to be. Being where you intended to be as opposed to where you need to be is failure - it means you executed to a strategic goal where all the signs along the way meant you were going in the wrong direction, yet you and your teams chose to ignore the signs anyway.

So, as a leader, can you coddiwomple?

(previously published as part of The Agility Series blog and on LinkedIn)

In my recent post on Strategic Planning versus Strategic Iteration I discussed three ways in which we need to adjust how we view strategy. In this short post I'll look at how we can identify the kinds of strategic changes we will need to undertake by asking four crucial questions. 

In our recent book Agile Value Delivery: Beyond the Numbers we offered up that:

"The primary reason for undertaking Portfolios, Programs and Projects is to enable the delivery of realizable Value into Business Operations".

This is the recognition that the primary origin of change in organizations is because something in business operations is not working or that the organization is wanting to go in a different strategic direction; but it starts and ends in business operations.

We also discussed the fact that organizations now face holistic messes rather than discrete problems coupled with increasing rates of change. Leaders need to learn how to lead at the pace of change rather than trying to control change.

Strategic Iteration helps us take an adaptive approach to how we approach the resolution of these holistic messes based on an Observe-Orient-Decide-Act mindset. But how do we specifically identify what we need to change and how do we make needed refinements based on what emerges?

Many organizations and portfolio teams have figured out that you need to take a holistic view of your organization in order to identify required strategic changes. But how do they do that? It starts with asking four crucial questions:

1. Where are we intending the strategic goals to be directed? Can be geographic, customer segments, distribution channels, etc.
2. Who are the primary players for whom the goals will provide some benefit?
3. What capabilities will be needed to do this and if we don't have them how will we acquire them?
4. Which of our existing systems, processes, structures or policies may be affected?

The real fun, as they say, happens once you get started. Strategic Goals and Objectives are statements of intent not statements of a defined scope and plan that cannot be changed.

An Adaptive Strategy based in Strategic Iteration is an approach that allows us to continually refine both our strategic goals and strategic objectives as well as the strategic changes we are targeting based on what emerges once we start to execute our strategies. 

In my recent webinar on The Adaptive Strategy Framework I discussed a framework that organizations can use to answer these and many other questions using strategic iteration, rather than strategic planning to solve the holistic messes they now face, by continually refining their approach during execution based on feedback loops of what is working and what isn't.

What questions do you ask to identify the strategic changes you need to make to meet your organizations strategic goals? I'd love to hear about them.