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.

This is the fifth blog in a series dealing with the challenges and excitement managing “informationally diverse teams” of experts.   My goal is to communicate the challenges, fun and “things that have worked” in managing projects team that has widely different backgrounds, experiences, education, and understandings.  Informational diversity is based on different functional, educational and industry backgrounds that constitute information and knowledge resources upon which the team draws

THE FIRST FOUR CROSS-FUNCTIONAL TEAM BLOGS:

1. Herding a group of cats, cows, sheep, goats, dogs and llamas…. http://bit.ly/2cr0ddH

2. How hard is it to herd a group of cats, cows, sheep, goats, dogs and llamas?  http://bit.ly/2c6n3Gv

3. Cats, cows, sheep, goats, dogs and llamas *CAN* be herded.   -  http://bit.ly/2cLpS2w

4. Things that have worked leading Informationally Diverse Teams - http://bit.ly/2cfkKka

NASA PROJECTS

“Projects are the means by which NASA explores space, expands scientific knowledge, and performs research on behalf of the nation” - from the NASA Project and Program Management handbook.  NASA/SP-2014-3405 which can be downloaded (free) http://go.nasa.gov/2chNXuO 

While the NASA project management handbook is very closely aligned with the PMBOK guide, there are some important exceptions.  One being the absolute requirement for monthly status reviews (more on this in a later blog)

PROBLEMS WITH CROSS FUNCTIONAL TEAMS

Managing a cross-functional team can be very difficult.  People are certain they are right, they KNOW they are right and everyone else just can’t see the truth.  There are many well-documented studies showing some of these frustrations.  When I give a talk on this topic, I ask people to raise their hands if they’ve experienced any of these issues.  A lot of hands get raised!

• Cross-functional new product teams had difficulty getting their products to market (Steiner, 1972; Hackman, 1990, Dougherty 1992)
• Innovativeness is actually lower with cross-functional teams (Ancona and Caldwell, 1992)
• Managers express frustration with the time and resource demands of functionally diverse teams
• Cross-functional teams often prove ineffective at capitalizing on the benefits of their informational diversity (Stasser and Titus, 1985, 1987)
• Difficulty motivating members to work together effectively (Dumaine, 1994)
• When groups benefit from informational diversity –  members report the experience frustrating and dissatisfying (Baron, 1990); Amason and Schweiger (1994)
• Workgroups disagree about task content or how to do the task (Jehn, 1997)
• Groups with members of diverse educational majors experience difficulty defining how to proceed (Jehn, Chadwick,and Thatcher, 1997)

THINGS I’VE TRIED THAT HAVE WORKED

Again, I didn’t start off knowing these things – I had a lot of mentoring (formalized), plus I failed a lot.  So these tips come from years of “falling forward.”

Number 1: Establish a sense of Mission (blog 4)

Number 2: Establish a Communications Framework That Works 

Neville Chamberlain famously established a set of war rooms in 1939.  Churchill visited the Cabinet Room in May 1940 and declared: 'This is the room from which I will direct the war'. In total 115 Cabinet meetings were held at the Cabinet War Rooms.  What were the advantages of a war room?  COMMUNICATION.  Everyone saw the same maps, the same schedules, the same plans and could talk about them.  It was “total emersion” into the project problem. 

Today there are many electronic, internet-based versions of war rooms, and they can work well.  But the physical war rooms still exist.  Google has used its war rooms for over 80 startups! 

Not matter what technology you use - do it – CREATE A WAR ROOM.  A central repository of information where everyone can see the same material at the same time.

Here’s a corner of one of my own war rooms from a $46-million-dollar project.  What you are seeing is actually the network diagram of the project – along with a LOT of notes, photographs of the progress to date, completed “nodes” of our network.  

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

MAKE AN ONLINE / EARLY RESERVATION TO TALK TO ONE OF OUR EXPERTS HERE! 

(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.

Is patient care a project? Is project managing a patient different from a project of a non-healthcare domain? A debate that runs through the minds of healthcare professionals as myriad of thoughts cloud their mind. And if it is, what’s the benefit of managing it like a project?

Well, the answer is both yes and no! Patient care can be likened to the project and yet be different in the way that it does not/need not adhere to the project management framework. First part first…..

A patient’s disease or condition has a definite start and end and hence is temporary in nature. The end here could be the control or cure of the disease. As the diseases are variable in their durations, the care involved can also vary with the disease duration. For example, diseases can be acute (short term, such as the flu or common cold) or chronic (long term, such as diabetes mellitus, heart disease, cancer, immune deficiency disorders, and so forth); hence, the duration of care differs with each of these diseases. Although projects are considered to be temporary, the result can outlast the project itself. For example, if we imagine a patient’s immunization program to be a project, then, the program is temporary and unique, and the result outlasts the project. In this case, the immunity gained by these immunization programs lasts a long time, even lifelong in some cases. Similarly, the control or cure of a disease outlasts the project of patient care.

The treatment of each of these diseases, although carried out by a certain repetitive set of people—nurses or physicians—is unique and delivers a unique result, which means that the patient’s condition can be controlled or cured or, at times, the result can be a lifelong disability.

So as you noticed, patient care can be conceptualized as a project and the best practices of project management can be applied to patient care for an end-to-end understanding and management of the same.

Patient care is, in many ways similar to projects of other domains. As project management framework cuts across domains, it surely can be applied to managing patient care. Key points that a project manager of a patient must remember are

1. Patient’s condition can change to worse at any point and that appropriate risk management must be in place to manage such life-threatening situations
2. Communication plays a key role in keeping all the stakeholders in sync on the prognosis. It helps get the right buy in and concur to the treatment plan
3. As is the case in other projects, finances to fund patient care can turn out to be a major constrain. It is important to talk to the patient care executive to get an idea of the expenditure
4. Patient’s care plan runs through highway with a many a traffic cones placed at different places. The dependencies are not clear at all times. It’s important to draw a schedule of plan and work iteratively to define and refine it and most importantly
5. This project deals with “life” of the patient – the core and basis of healthcare!

Let’s see how a project is initiated in the next post….

Look forward to meeting you all and talking to you ….will be glad to share my thoughts and clarify your questions on this confluence domain. Meet me at the Global Congress Solutions Center in San Diego (25^th – 27^th September 2016). Can make it? Find the information on the sessions as well as sign up to ask questions

http://congresses.pmi.org/NorthAmerica2016/sponsors/hours-overview

Looking forward…

Sustainability is a topic that is always on my mind, or rather, how we can do a better job of addressing past and current social and environmental impacts, how we might live more sustainably, and most importantly, how we might proactively plan future products and developments in a responsible, sustainable manner.

When it comes to the last point, I speak and write about this topic quite frequently, with a particular focus on the industrial sectors, an area that often causes a lot of controversy between business and the general public.

A few major things come into play to cause problems for these projects –

1. Historic performance and failures of the extractives sectors – environmental damage caused from past practices, abandoned and un-reclaimed mine sites, and tailings dam and pipeline failures. These have created a low-trust state for businesses within these sectors.
2. Most of the general public is not well-informed about the regulatory performance requirements, nor the extensive engagement and review process and approvals now needed before industrial projects proceed. As such, they are led by information distributed primarily by the media, driven by those who might disrupt impartial review processes, or yell the loudest, with constant reference to historic practices to ensure support – the opposition.
3. Business, while it is getting better, does not have a great track record of external stakeholder engagement and inclusivity. Meaning, community leader input, concerns and objections are not always heard, they are under-valued, and sometimes may simply not be sought out. Or at least not until a project’s studies are much progressed.
4. As a result of poor engagement, external stakeholders that might be directly impacted may not become aware of proposed developments, or understand the real and potential impacts of them, until late stages of planning and design.

So, the situations that tend to arise are protests, delays of approvals (for example the XL Keystone pipeline), and even outright work stoppages, if construction approvals were somehow granted without gaining agreement from all external stakeholders (even landowners). This is the case for the current Dakota Access Pipeline project, if anyone has paid attention to media coverage on the protests.

I’m reiterating here, but in the extractives sector, studies have shown that up to 70% of project delays (and the costs associated with those delays) are caused by social and environmental challenges.

And having read a number of reports on causes of project failure rates in general, I would be willing to bet that these sustainability issues cause delays for other sectors as well, just perhaps to a lesser degree.

In my opinion, what most of this boils down to is:

• Managing projects where we might have a lack of understanding about relevant issues and regulatory requirements of the sectors we are working within,
• Insufficient value recognition, or lack of training, for good engagement and/or communications,
• Incomplete identification of risks and requirements, and as such – incomplete plans,
• Mis-aligned teams and stakeholders, and
• Challenges with project agility.

While the first point may not be as common, the rest are seemingly common themes within the project management community, no matter what the sector – a simple observation anyone can make from a scan of the articles and support available online to project managers.

So our projects aren’t so different after all, are they?

Without appropriate engagement and communications, project teams are bound to miss critical requirements for their project – and as such, develop an incomplete scope to proceed. PMI’s own studies clearly show that poor requirements management (including identification of them) is a primary cause of project failure.

Without ensuring we are all well-aligned to the ultimate project goals, and to understanding when it might be okay to shift strategies to get there, we set ourselves up for failure.

Without the ability to “coddiwomple”, without taking a staged and iterative approach to our projects, and without a willingness to adjust scope and make alternate decisions, as more information is obtained, it is then inevitable that the ultimate goals of the project are put at risk.

But we like to lock in scope, to avoid the management of change, right?

I urge you to stop and think about your project’s ultimate goals.

• Have you ensured you’ve addressed all the risks and requirements to achieve success? 
• Have you been willing to adapt scope as required to achieve them?
• Have you taken the time to learn what might help you achieve greater outcomes?

A team representing various areas of expertise will be located in the exhibition hall in the “Ask the Expert” booth at the upcoming North American PMI Congress in San Diego. 

I’ll be there to help answer any questions you might have about sustainability, integration of these issues into project planning, and stakeholder engagement. Come find me!

Can’t make it and still have questions? Post them here, or connect with me on LinkedIn, or Twitter and send me a message that way. I’d love to hear from you!