Skip to main content

Author: Drew Davison

Drew Davison is the owner and principal consultant at Davison Consulting and a former system development executive. He is the developer of Project Pre-Check, an innovative framework for launching projects and guiding successful project delivery, the author of Project Pre-Check - The Stakeholder Practice for Successful Business and Technology Change and Project Pre-Check FastPath - The Project Manager’s Guide to Stakeholder Management. He works with organizations that are undergoing major business and technology change to implement the empowered stakeholder groups critical to project success. Drew can be reached at [email protected].

From the Sponsor’s Desk – Ignore These 7 Lessons at Your Project’s Peril

I have a passion for proven best practices. They are the collective wisdom of others who have gone before.

They can improve performance, reduce risk, accelerate delivery and increase satisfaction. They can be revised or discarded as appropriate. New ones can be added. But they should never be ignored.

In the following case, you’ll see how one project faired when the CEO dictated a certain course of action. Those charged with carrying out the project chose to carve a new path and ignored the lessons learned by others. They paid an all too familiar price.

Thanks to R.D. for the details on this story.

The Situation

This industrial services company had grown successfully over the years through a practical strategy of strong organic growth and complementary acquisitions. The company’s head office serviced the northeast. Five other regional offices covered the major metropolitan areas in the rest of the country.

The new CEO recently hired to replace the retiring leader, found the culture somewhat foreign. He was used to a fast paced, competitive, often combative environment as head of marketing in his old firm. At his new company, the pace was slower, more collegial, almost familial. But, what irked him most was the almost complete lack of instant access to key corporate performance indicators. Three of the regional organizations had been acquired. Business processes and supporting technologies were a hodgepodge of disparate purchased and home grown solutions. Getting an accurate and timely view of enterprise operations was costly and time-consuming.

His old firm had been a much larger organization. Prior to his arrival, it had implemented a full spectrum Enterprise Resource Planning (ERP) solution that covered all the vital corporate functions including customer management, sales, procurement, distribution, inventory, accounting and human resources. It also provided executive dashboards so senior management could tap in and drill down on actual corporate performance at will. This capability wasn’t available at his current company.

The CEO was frustrated with this lack of access to operational information. While his senior management team and the regional general managers didn’t seem to be bothered by the current situation, the CEO knew they could do a much better job of managing the company’s performance with better access to information. So, he launched a priority project to remedy the situation, holding the VP of Information Services (IS) responsible for making it happen. The CEO called the project “Insight.”

The Goal

The goal of the Insight project was to deliver a comprehensive ERP solution covering head office and the five regional offices within eighteen months. The project was to use the software and vendor services that the CEO’s previous firm had used. The project’s scope would cover customer management, sales, procurement, distribution, inventory, accounting and human resources functions. All senior managers were to have access to the executive dashboards.

The Project

The VP of IS and the vendor’s Sales Director met to review the CEO’s challenge. They agreed to proceed as follows:

  • The vendor would appoint an experienced senior project manager to run the overall project.
  • The project manager would report jointly to the vendor’s Director of Contract Management and the VP of IS.
  • The project would include the functionality specified by the CEO.
  • The VP of IS would ensure that sufficient subject matter expertise was available from the affected head office and regional office business and IT groups.

When the vendor’s project manager was on board, he contacted the VP of IS and the regional managers requesting subject matter experts from the affected business units and IT to participate in the project. He proceeded to build his own team with analysts, programmers, database resource, and training staff. He also started to build a high-level plan based on his experience in two previous ERP implementations with the vendor. He knew the eighteen-month target would be a challenge, so he developed a strategy to accelerate delivery as much as possible:

  • Use the vendor functionality as delivered out of the box to reduce the need for revisions and custom code.
  • Any deviation from the standard functionality would need to be approved jointly by the VP of IS and the vendor to minimize scope creep.
  • Deliver the change as one major implementation to avoid the incremental time and costs that could be incurred to phase delivery by function and/or location.

The PM proposed that he could deliver to the stated goals in the targeted eighteen months at the cost of $2.5 million. He received approval from the VP of IS and the vendor on his overall strategy and plan and so proceeded accordingly. He immediately ran into challenges:

  • The subject matter experts were not available or late in arriving.
  • Many of the so-called subject matter experts assigned weren’t experts.
  • Each of the locations had its own unique processes, applications, and technologies. That meant six conversions instead on the one he had planned.

The PM filed bi-weekly status reports for the vendor and the VP of IS using the vendor’s standard reporting format. His first report, two weeks after his assignment to the project showed green for schedule, cost and scope. His second report, in one month then showed red for schedule, cost, and scope. Every subsequent report showed red across the board. He couldn’t get the staff he needed, with the skills he needed, when he needed them. As each of the locations began to understand the functionality available in the standard offering, the change requests escalated into the hundreds and eventually thousands. The vendor management and VP of IS were slow to rule on the requests. They rejected the initial onslaught out of hand to preserve the CEO’s eighteen-month target. That resulted in local escalations to head office and regional office business executives who vehemently descended on the VP of IS and the CEO.

The first project manager was replaced after six months with two PM’s, one from the vendor and one from the Information Services organization. Still, everything the project did was focused on meeting the eighteen-month target. When it became obvious that was not achievable the emphasis was still on the delivery date above all else, still marching to the original PM’s strategy.

The Results

The Insight project took more than five years to complete, at the cost of almost $7 million. A disastrous attempt at a one time, big bang implementation two and a half years into the project contributed to a 27% corporate revenue decline. The initiating CEO and VP of IS were fired. The first two and a half years of the project up to and including the failed implementation and subsequent recovery burned through $5 million.

After the failed big bang implementation, the new CEO and VP of IS brought in a consulting firm to take on overall control of the project. The consulting firm’s approach was to treat the initiative as a program, with six separate and discrete projects covering head office and the five regions, all moving to a consistent, common business, application, data and technology infrastructure. The CEO was the executive sponsor. The five regional general managers were sustaining sponsors. Each project was run in parallel, in accordance with the capabilities and priorities of the target organization. Each project was phased in on a function be function basis to reduce risk and build a continuous delivery culture. This part of the project was completed successfully in two and a half years, at the cost of $2 million.

How a Great Leader Could Have Succeeded

There are more than a few failed ERP project examples. You’ll probably get over half a million or so items if you do an internet search. There may be some duplication in there, but it’s still a sufficiently large number to suggest the need for caution and some thorough research on how to avoid the pitfalls.

To help you on that quest, here are the critical lessons learned from this case. And, they’re relevant to any project, not just ERP endeavors.

  1. This was not an IT project – Yes, the project involved technology change. These days, most do. But more importantly, it required significant changes in business processes and practices throughout the organization. To give responsibility for the project to the vendor and VP of IS sealed the project’s downfall from the beginning.
  2. Build and manage the guiding coalition – The consulting organization that ran the second part of the project had the players right. The CEO was the overall sponsor. Sponsorship can’t be delegated. The company had a long history of local control and local solutions. The regional GM’s had an enormous part to play to help transition disparate operating environments to one common platform. In the first fateful stage of the project, they were reduced to human resource providers. Culture eats change for breakfast.
  3. If you don’t know where you’re going, you’ll end up someplace else – So said, Yogi Berra. The simplistic dictate from the CEO emphasizing time to delivery was lunacy. The fact that nobody challenged it was evidence that the right players weren’t sitting at the table. The regional GM’s would have objected strenuously. They would have insisted on factors like sustaining and improving customer service, minimizing operational disruptions, affordability of the target solution, return on investment, and other relevant and essential targets.
  4. Decision making is an ongoing exercise – A project starts out as a shady gray blob with little in the way of the necessary details. As it progresses, the gray blob gradually gives way to light and insight. Each bit of light added requires a decision to move the understanding, and the project, forward. Therefore, clarity on the decision-making roles, responsibilities and accountabilities is paramount. The first PM attempted to circumvent the need for progressive decision-making with his strategy to use the functionality out of the box. Consequently, in the early stages of this project, that clarity and some key decision makers were missing in action. It just got worse from there.
  5. Small is beautiful – Frequent implementations are a must, to provide learning opportunities, to build a culture of success, to manage risks, to deliver value incrementally. We also know that small implementations have a much greater track record of success.
  6. Skills, skills, skills – One of the early warning signs identified by the first PM was the lack of human resources with the necessary knowledge and skills. Having a lovely software suit may be necessary, but it’s not sufficient to deliver a lasting solution. Enough people with the right skills at the right time is the force multiplier. That issue was only resolved when the regional GM’s were brought on board, and they had a stake in the game.
  7. The medium is the message – The first PM prepared and distributed his status reports for the vendor and the VP of IS every two weeks. Using the same status reporting process repeatedly might be efficient, but, in this case, it didn’t drive the necessary reactions and remedies. Status reporting needs to adapt the timing, content, and delivery to the circumstances to gain the attention of diverse audiences and the reactions needed to fix the challenges identified.

You’ve heard these points before. They’re not new. They’re not magic. But they do work. So, be a Great Leader and put these points on your checklist of things to consider on your next project so you too can achieve great results. And remember, use Project Pre-Check’s three building blocks covering the key stakeholder group (including the key stakeholder roles), the decision management process and Decision Framework best practices right up front, so you don’t overlook these key success factors.

Finally, thanks to everyone who has willingly shared their experiences for presentation in this blog. Everyone benefits. First-time contributors get a copy of one of my books. Readers get insights they can apply to their own unique circumstances. So, if you have a project experience, good, bad and everything in between, send me the details, and we’ll chat. I’ll write it up and, when you’re happy with the results, Project Times will post it so others can learn from your insights.

From the Sponsor’s Desk – Transforming Projects with Architecture

Architecture has had a significant impact on humanity over the centuries, whether in the form of planned structures, environments, societies, frameworks or technologies.

In the technology sphere, architectural practices have contributed to everything from chip designs, to communication protocols to design and code repositories. Generally, things that receive architectural attention are of higher quality, cost less in the long term, perform better and receive higher levels of satisfaction from all stakeholders. But, is there an easy way of achieving those benefits on individual projects, of transforming projects with architecture?

In the following case, you’ll see how one organization used their architectural passion for slicing and dicing individual projects into their component parts, delivering better, faster and cheaper solutions while building reusable foundations for the enterprise.

Thanks to L.D. for the details on this story.

The Situation

In this medium sized financial services organization, senior technology and business leaders from the four lines of business would often hang out at a local pub on Friday afternoons. The gatherings were informal and largely social. On any given Friday afternoon, the numbers could range from two or three to more than ten. On occasion, one of the business leaders would talk about a planned project and ask for advice from the other participants. Periodically, one of the technology leaders would chat about an emerging technology and look for feedback on potential opportunities and impacts.

Over time, the informal gatherings became a vital hub for advice and sharing. Often, instead of booking a meeting in the office to discuss a planned change, participants would confirm attendance at the Friday afternoon gathering. Depending on who was in attendance, the informal discussions often revealed multiple perspectives about the project that would have a beneficial impact on subsequent planning and delivery efforts.

The head of the database group, let’s call him John, saw what was happening with the Friday gatherings and thought there would be significant benefits in formalizing the process. So he sent out a proposal to the usual attendees and suggested it be discussed at the next Friday afternoon gathering, of course. Fifteen business and technology leaders showed up, including a number of first-time attendees invited by the regulars. They kicked the idea back and forth and managed to reach a consensus – let’s pitch it to the executives. John agreed to lead the effort.

The Goal

The Friday afternoon pub group agreed to a target vision to accelerate project deliveries while reducing costs and improving development and operational quality. Their goal: a framework that would identify the business, information, application and technology components required to support a project that could be developed in parallel to accelerate one solution and be reused by others. They agreed to pursue approval of the following approach:

  1. Submit every project to a review by domain experts to identify opportunities, impacts, and shareable components.
  2. Use the review to partition the project into component parts, including business processes and functions, hardware, software and communication technology components, shareable code for business and technology objects and interfaces and components for human and technology consumers.
  3. Build the processes and facilities required to operate the review and launch exercise over time based on the individual project experiences.
  4. Above all, accelerate delivery, improve quality and deliver reusable components.

Essentially, every project could become a mini program with multiple businesses, object/data, technology and application components, built in parallel and assembled to deliver the final solution. The diagram below, initially sketched by John on a pub napkin and circulated to the attendees, became the official target.

Davison 031617 1

The Project

John and a few of the other senior business and technology leaders from the Friday pub group took their idea to the CIO. He was a traditionalist with a computer operations background. They sold him on three key principles:

  1. Technologies were developing and expanding at an ever increasing rate. He agreed.
  2. The organization’s business lines would require support for many of these technologies because of customer demands. He was already experiencing that trend.
  3. Using priority business projects to assess a technology’s viability would address the needs of the individual projects while driving infrastructure capability to serve the entire organization. He loved the idea of the IT infrastructure being ready before the business needed it. He agreed.

John, the CIO and the business leaders from the Friday afternoon pub group took the idea to the executives, one at a time. They would have to buy in for the proposal to work. The agreement was reached one after one including the CEO. Then the real work began.

John and the other pub group members formed the initial review team:

  • Corporate architecture – John (chair)
  • Business lines
  • Infrastructure
  • Software development/delivery
  • Project management
  • Computer operations

There were some obvious knowledge gaps, particularly around the inter-relationships among the various points of view – for example, which business lines used which applications, objects/data, technology, etc. They decided to build their knowledge as they went.

The group started with the current year’s approved project portfolio. They sat down with the owners of the priority projects, explained the approach and asked for the owners’ support and participation. They then took the first ten projects through the process. Here’s what they discovered:

  • The process was more difficult than it sounded.
  • The group’s leaders found the process was taking considerable amounts of their time, so they started orienting and involving some of their senior staff to carry more of the load.
  • Other than the broad generalities of their vision, they didn’t have metrics to help them gauge how they were doing and how the organization was benefiting.
  • They found that some of the component initiatives launched to support a project were more expensive than the individual project could afford.
  • On a couple of projects, they discovered that the total time and effort needed to deliver the identified component pieces would be significantly greater than what would be required to deliver the project in the traditional way.
  • In a number of areas, they lacked the processes and methodologies to develop, deliver, test and operationalize reusable components.

The group’s progress and findings were communicated openly with senior management and project owners and received lots of attention at the Friday afternoon pub sessions. The group responded by tackling each issue as it arose. To tackle the issue of process complexity, they started focusing on the low hanging fruit. Yes, they left some potentially valuable reusable components on the table, but they delivered quality solutions quickly. To address the metrics gap, they started tracking components reused, the number of subprojects per project and elapsed time cut using actual time as a percentage of an initial estimate established by a subgroup of the team. They also started documenting the processes and practices that were adding value for future use.

Perhaps the biggest stumbling block the team encountered was on the cost front. They established another metric on total actual costs versus estimated cost, using as a proxy the expected benefit times required payback period. For example, if the estimated cost proxy was $750,000 (expected benefit of $1 million annually times required payback of 9 months), and the actual cost for all subprojects was $1.5 million, the total actual costs versus the proxy for estimated cost would be 2, or twice what it would have cost doing things the old fashioned way.

Obviously, they needed to get that number to 1 or less. However, in the short term, while they were building reusable components and not able to reuse a lot, they needed a mechanism to take a project’s business owner off the hook for the extra cost. The method they came up with was to establish a separate infrastructure investment fund that would pay for any extra costs above and beyond the estimated cost. The business leaders loved it. The company’s executives approved it and provided funding of $3 million annual for the first three years.

The Results

Over the first three years of this process, the results rewarded the company’s faith in the exercise:

  • A number of components reused went from zero to an average of 26 per project.
  • A number of subprojects per project went from 3 in the early days to 11 at the end of the third year, indicating much more parallel development was taking place.
  • The elapsed time reduction went from 1.3 (more time) on the first few projects to .85 (less time) due to reuse and parallel development.
  • Estimated cost versus actual cost went from 2.3 (significantly more expensive) to 1.2 (a bit more expensive). There was still some money left in the third year’s infrastructure investment fund at the end of the year.

Transforming projects with architecture!

Needless to say, all the stakeholders involved in this change were enthusiastic about the results. There were also other results which had not been anticipated. They discovered that breaking the projects up into their component pieces resulted in smaller, more predictable initiatives with fewer surprises and more reliable cost and timeline estimates. In spite of significantly more production change activity, production problems actually declined by more than 30% over the three years. As well, unforced staff turnover was down by 50%, and the annual employee satisfaction surveys showed record increases, mostly attributable to the emergence of an exciting, collaborative culture. Transforming culture with architecture!

How Great Leaders Delivered a Transformation

This change wouldn’t have happened without the weekly pub group. The participants were in a convivial environment, relaxed, and ready and willing to share some enjoyable chitchat, engage in wide-ranging discussions and give and take. It also wouldn’t have happened if someone, John in this case, hadn’t seen the germ of an idea and had the courage to shape it and present it to his group mates.

The actual practices presented here are difficult to apply on a project by project basis. Somewhat like project portfolio management, architecture needs some help from higher up the food chain. However, there are a few learnings from this case that any project manager or team can leverage:

  • Share your ideas – Don’t hesitate to look for opportunities and share your observations. Let others contribute to shaping the vision.
  • Take it outside of the office – Look for a relaxed venue outside of the office to exchange musings with friends and colleagues. A pub is a great venue but an off hours food court, a park, a walk around the block can also work.
  • Embrace diversity – Don’t just hang out with the folks you normally encounter. If you’re in IT, engage with some business staff and vice versa. Include your boss, or your staff, or the boss’s boss. Include some customers. Be open to new perspectives, different ideas.
  • Start small – John didn’t have all the answers, nor did the pub group, nor did the CIO or the executives. The germ of an idea was enough to get started.
  • Break it up – The review team discovered that there were benefits to breaking projects into their component parts beyond the reusability opportunities, including better time and cost estimates, greater predictability, better quality and the opportunity for parallel development.
  • Build proficiency incrementally – The review team could have taken six months to draft processes and procedures to help guide the way. Instead, they jumped in learning while doing and sought help when they ran into problems.
  • It’s all about the journey, not the destination – All the stakeholders signed on to a journey of discovery. They didn’t know how much was in the pot of gold at the end of the rainbow. And it didn’t matter. They’re still on the journey.

So, be a Great Leader and put these points on your checklist of things to consider on your next project so you too can achieve great results. And remember, use Project Pre-Check’s three building blocks covering the key stakeholder group (including the key stakeholder roles), the decision management process and Decision Framework best practices right up front, so you don’t overlook these key success factors.

Finally, thanks to everyone who has willingly shared their experiences for presentation in this blog. Everyone benefits. First-time contributors get a copy of one of my books. Readers get insights they can apply to their own unique circumstances. So, if you have a project experience, good, bad and everything in between, send me the details, and we’ll chat. I’ll write it up and, when you’re happy with the results, Project Times will post it so others can learn from your insights.

From the Sponsor’s Desk – Project Management Meets Design Thinking

The practice of Design Thinking has received accolades for transforming the way organizations solve problems.

At the core, Design Thinking is about driving decision making from the human perspective, where business, organizational and technological solutions evolve from a human-centered exploration.

Design Thinking practices offered by Stanford’s d.school, IDEO, IBM, GE and others are characterized by reimagining exercises, wide collaboration, rapid iteration, prototyping and testing cycles and a tolerance for failure. So, what happens when traditional project management meets Design Thinking?

In the following case, we will journey along with a project manager as he explores what an executive-mandated Design Thinking initiative means to his job. We’ll discover what he has to change to ensure the identified problems are addressed and the targeted solutions are delivered successfully, with Design Thinking as a key element of that process. Project management meets Design Thinking.

Thanks to G.A.D. for the details on this story.

The Situation

The Marketing Vice President for this North American retailer had a problem. While sales in the bricks and mortar locations were doing well, sales on the company’s web site were languishing. That was especially troubling because their competitors were showing significant, double digit sales growth through their internet offerings.

The company had over a hundred thousand customers using their loyalty card. They ran weekly email promotions to that base. They ran weekly print and online sales promotions as well. All the material featured their web site and the ease of online shopping. But it wasn’t increasing web site traffic and sales.

The Marketing VP had tried changes to their web site interfaces and functionality. He had sponsored the development of an application for customers to run on their smart phones, tablets and PCs. He had even offered discounts for first time online purchasers. But it wasn’t increasing web site traffic and sales.

Out of frustration, the Marketing VP decided to try something completely different. He had read a number of articles about a practice called Design Thinking and its ability to transform corporate performance by focusing on the customer. So he contracted with a firm that had a solid track record on Design Thinking engagements to help his organization rethink its approach to online marketing and service.

But, the Marketing VP knew this undertaking could be a sizeable project. So, he brought in an experienced Project Manager to oversee the venture. The selected PM had no experience with Design Thinking but he was a capable, trusted manager with over ten years of successful delivery and satisfied clients inside the company.

The Goal

The Marketing VP named his new project “Project Resonate” and set three specific targets:

  1. Increase online sales activity by 30% annually by the end of year one
  2. Deliver the solution within nine months
  3. Spend no more than $1.5 million. That amount would allow the company to break even on the investment within one year.

The Project

The new project manager, let’s call him Robert, had heard the term Design Thinking and had scanned recent articles on the subject but had no in-depth understanding. So he went to work, reading, researching and discussing the subject and his role in managing a Design Thinking initiative. He met with the Design

Thinking Facilitator (DTF) assigned to Project Resonate by the contractor and was thrilled with her level of expertise and her thoughts on how their roles would operate. They agreed to the following:

Robert, as overall Project manager, would be accountable for:

  • Managing the relationships with the project sponsor (the Marketing VP) and other key stakeholders.
  • Defining, implementing and running the governance practices reflecting the company’s current dictates, including appropriate processes and practices. On this project, Design Thinking would be one of those.
  • Developing and managing the change management plan.
  • Developing and managing an overall project management plan.
  • Planning and tracking project financials.
  • Reporting on project status to all interested parties.
  • Identifying and supplying needed resources and facilities.
  • Developing and managing the risk plan.
  • Developing and operating change and issue management processes.
  • Developing and running the communication plan.
  • Identifying and socializing lessons learned.

The DTF, as the primary Design Thinking resource, would be on the hook to

  • Articulate the objectives for the Design Thinking effort and the problems that are being addressed.
  • Design and plan the group processes.
  • Select the tools that best help the group progress towards the desired outcome.
  • Guide and control the group process to ensure that:
    • There is effective participation,
    • Participants’ boundaries are challenged,
    • Participants realize a level of mutual understanding,
    • Participants’ contributions are considered and included in the ideas, solutions and decisions that evolve,
    • Participants take shared responsibility for the outcome.
  • Ensure that outcomes, actions and questions are properly recorded and actioned, and appropriately dealt with afterwards.

With their respective roles and responsibilities out of the way, Robert and the DTF worked together to develop the approach and plan for the Design Thinking stage. The DTF used a five step approach to elicit and prove potential solutions, with opportunities to iterate at each step as often as needed.

They identified the participants who would be needed, including actual customers and representatives from the business and technology units affected. They drafted a message for the Marketing VP to send to the target participants explaining the challenge the company was facing (in customer terms) and asking for their assistance. They planned the initial workshop – a four day affair. They mapped out the timeframe for the first cycle and booked the facilities to accommodate the workshops and reviews. They also agreed to limit the scope in the first session to three high level goals (Epics in Agile parlance).

Davison 021317 Design Thinking Process

And so the work got underway. Early on, Robert experienced an aha moment. As he watched the Design Thinking efforts unfold, he realized Design Thinking was just another set of skills and practices that could be leveraged to help solve a problem and deliver a successful outcome. Of course, it was a vital practice because it set the stage for everything that would follow. But, in reality, from a project management perspective, it was no different from any number of other essential skills and practices, including agile software development, lean/Six Sigma and other business analysis and design approaches, data management, technology architecture, programming and testing in all their forms, change management practices, and so on. They were all best practice based learnings that could deliver amazing value, depending on the nature of the project. They all deserved a place in the project manager’s tool box.

The Results

The Design Thinking effort on this project produced three high level goals and a number of prototypes over six weeks. Three of the prototypes went on to be developed and released into production in three sequential releases.

The project was completed in a little over five months at a cost of $650,000. After twelve months, web site hits had more than doubled and sales had increased by over 50%. Not bad for a Design Thinking first try!

Perhaps the most significant benefit from the project was a lasting passion for the process. The customers involved were truly excited by their experience. The company capitalized on that excitement in their advertising and promotion, with their customers’ approval of course. The company’s participants, business and technical staff alike, loved the energy and excitement of the problem solving and creative processes and demanded the same experience in follow-on projects. The Marketing VP insisted on Design Thinking front and center in his future endeavours. Others in the executive suite took notice. Design Thinking became a company obsession.

How a Great Leader Embraced Design Thinking

In most “traditional” projects, the target solution is known. The challenge is to figure out how best to deliver and get it done on time and budget. In a Design Thinking world, the challenge is different. Of course there will be some thoughts about the possible “solution”. But the real emphasis is on collaborative exploration leading to rapid prototyping and human-centered testing. It is a voyage of discovery, marrying customer, business and technology perspectives to deliver a solution that satisfies.

Robert’s early realization that Design Thinking was just another essential tool to add to his tool box was a breakthrough. It made the inclusion of the Design Thinking effort in his project just a normal part of his PM job – always select the best tools available for the task at hand and adapt them as needed. The experience also cemented in Robert’s mind his top eight beliefs – for serving his clients well and getting maximum enjoyment out of every assignment:

  1. Understand the customer’s point of view
  2. Collaborate with all stakeholders
  3. Emphasize the journey, not the destination
  4. Ensure the people, tools, services and resources are equal to the task
  5. Be adaptable
  6. Embrace risk, accept ambiguity, learn from failure
  7. Iterate
  8. Rapid delivery is essential.

So, be a Great Leader and put these points on your checklist of things to consider so you too can achieve great results. And remember, use Project Pre-Check’s three building blocks covering the key stakeholder group (including the key stakeholder roles), the decision management process and Decision Framework best practices right up front so you don’t overlook these key success factors.

Finally, thanks to everyone who has willingly shared their experiences for presentation in this blog. Everyone benefits. First time contributors get a copy of one of my books. Readers get insights they can apply to their own unique circumstances. So, if you have a project experience, good, bad and everything in between, send me the details and we’ll chat. I’ll write it up and, when you’re happy with the results, Project Times will post it so others can learn from your insights. Thanks

From the Sponsor’s Desk – The Six Secrets of Project Prosperity

Imagine this. Your boss asks you to work with eight countries in West Africa.

The assignment: to support the establishment of practices for the effective and equitable operation of microfinance lending to small and medium size business clients in the region. He tells you it’s vital to the growth of the local economies and to the region as a whole.

That request is probably well outside the comfort zone of most project managers. It’s hard to image where you’d even start. But CESO knows. In fact, they do this kind of thing all the time, with limited financing, a small full time staff of fifty, and a core of seasoned Canadian volunteers. They deliver successfully, time after time, using what I call the six secrets of project prosperity.

Thanks to Leah Oliveira, Director, Communications and Engagement at CESO for the details on this story.

The Situation

The mission of the Canadian Executive Service Organization (CESO) is “to strengthen economic and social well-being in Canada and abroad through engagement of skilled and experienced Canadian volunteers working co-operatively with partners and clients to create solutions that foster long-term economic growth and self-reliance”.

As I recounted in my previous post on CESO, Stronger Economies, Better Lives, CESO focuses on helping small and medium size businesses (SMB’s) as a catalyst for growing individual and community prosperity. Providing funding to those SMB’s is an essential component of that strategy. Unfortunately, traditional lending organizations aren’t always interested or able to serve those needs. That’s where microfinancing comes in.

Working with its network of government and non-governmental organizations, private sector enterprises, clients and its own staff and volunteers on the ground in West Africa, CESO identified available and effective microfinancing services as a foundational need for continued SMB growth and development. While microfinancing was often available, the offerings weren’t regulated to ensure SMB clients were protected from abuse. That posed a potential risk to borrowers and thus a constraint on SMB viability.

The Goal

The challenge, therefore, was to bring together the national microfinance institutions of eight West African countries to define, institute and administer policies and practices that would ensure safe and accessible microfinancing services throughout the region. Consistent oversight of microfinancing practices would enable lenders to achieve a reasonable return on their investments while providing SMB’s with access to the capital needed to start and grow their businesses without fear of abuse. It would also provide a unified, singular voice to work with regional institutions, governments, international partners, the regional central bank, and more broadly with the West African Monetary Union.

The Project

This program started almost twelve years ago and involved some fifty CESO Volunteer Advisors and other CESO staff over that time. Each assignment involved contact with current and prospective SMB clients or microfinance organizations along with other interested parties. The engagements would identify local needs and problems, potential future issues and concerns, current and future risks and opportunities, and potential remedies.
Over time, the outputs from these assignments were rationalized, assimilated into a broader body of knowledge that became a framework for collaboration across the stakeholders involved, locally, nationally and finally across all eight West African nations.

The Results

Those years of work culminated in the first annual general meeting of the West African Microfinancing Foundation in October of 2016.

Microfinance in West Africa is now a dynamic economic and social sector which empowers more than 9% of the total population in 8 countries (Benin, Burkina Faso, Ivory Coast, Guinea-Bissau, Mali, Niger, Senegal and Togo) of the West African Monetary and Economic Union. In comparison, traditional banking amounts to 5.5%. According to the available statistics, at the end of March 2015, there were 724 microfinance institutions in the affected region, attracting more than 13.8 million beneficiaries.

Continuing assessment of ongoing performance will focus on the following metrics:

  • Social return on investment,
  • Outreach or improved local credit markets – how many clients are being served
  • Collection performance – how well is microfinance collecting its loans
  • Financial sustainability – is the organization profitable enough to maintain and expand its services
  • Efficiency – how well does the organization control its administrative costs.

How Great Leaders Delivered

The six secrets that CESO used to achieve these great results are, in fact, the cornerstone of everything they do. They include:

  1. Mission, Vision, Culture – All of CESO’s operations are framed by their mandate established fifty years ago and mentioned at the start of this article. They are driven by local needs. Their main emphasis is always on strengthening and enabling local clients and partners through knowledge transfer and collaboration.
  2. Human capital – CESO’s focus is on building individual skills and capabilities in the private sector and supporting institutions. To that end, they select and assign highly skilled Canadian Volunteer Advisors to train and mentor local entrepreneurs and institutional staff to realize sustainable change. CESO has mentored and trained almost 6,000 people in their target communities over the last two years alone.
  3. The long view – We know that projects that are spawned by a strategic plan and guided by an organization’s strategic direction tend to be more successful on all fronts. So, it’s no surprise that CESO’s remarkable record of success can lay claim to a similar enabler. At least 85 per cent of CESO projects are conducted under the auspices of a Partnership Action Plan, including the microfinance initiative. The plan is developed by a CESO Lead Volunteer Advisor in collaboration with local partners. It provides the blueprint for assignments that will be carried out over the entire course of the multi-year timeframe. The remaining 15 per cent of projects are purposefully constructed under a “fee for service.” These projects tend to come from new, often smaller partnerships that serve in many ways as pilot projects for both CESO and the partner, many of which are developed into multi-year partnerships following the test project.
  4. Networks of Relationships – CESO’s Country Representatives look after business development on a country by country basis. They find and identify partners and clients, build and sustain those relationships, manage local government relations and liaise between CESO, the local, regional and national governments and Canadian embassies. The networks are formed and nurtured independent of any particular project. Yet, they are what allow CESO to frame the opportunities, engage the required stakeholders and launch initiatives quickly and effectively. The relationships, for the most part, are already in place.
  5. Partnerships – CESO’s partnership model is adaptable to different situations as well as being scalable to various sizes of enterprises and undertakings. The microfinance initiative involved the formation of partnerships across four levels in West Africa, with individual entrepreneurs, building capacity in local microfinance institutions, advising national micro-finance regulatory institutions and at a regional level with the West African Monetary Union. The overall partnership model facilitated and reinforced the formation and operation of those separate groups. That’s just the way CESO does business.
  6. Best practices – Every assignment and every project goes through a formal evaluation process with the participation of involved partners, clients and CESO staff. Lessons learned are formalized and add to the best practice body of knowledge to help improve future performance. CESO even has a formal position called a Knowledge Officer. People in this role are accountable for eliciting and sharing information and best practices and facilitate getting evaluative information back to CESO. If only every organization had a Knowledge Officer or two.

These six secrets to CESO’s continuing success are not generally what come to mind when one thinks about key project success factors. Nor are they always easy to implement in every project situation. In fact, most of these six secrets are typically beyond the scope of any one project. However, CESO’s track record demonstrates the power of the practices to produce consistently sustainable change.

So, be a Great Leader and put these points on your checklist of things to consider so you too can achieve great results. You might not be able to go all in on each practice. But perhaps going just a little way towards CESO’s secret six can give you that critical edge. And remember, use Project Pre-Check’s three building blocks covering the key stakeholder group (including the key stakeholder roles), the decision management process and Decision Framework best practices right up front so you don’t overlook these key success factors. You’ll find that CESO’s six secrets to project prosperity are included.

If you are intrigued by CESO’s mission and would like to learn more about becoming a volunteer advisor, at home or abroad, check out their website. It covers the skills they’re looking for and the steps involved to become a volunteer.

Finally, thanks to everyone who has willingly shared their experiences for presentation in this blog. Everyone benefits. First time contributors get a copy of one of my books. Readers get insights they can apply to their own unique circumstances. So, if you have a project experience, good, bad and everything in between, send me the details and we’ll chat. I’ll write it up and, when you’re happy with the results, Project Times will post it so others can learn from your insights. Thanks

From the Sponsor’s Desk – Fixing Uncommitted Sponsors

We know that actively engaged sponsors are a critical success factor in effective project delivery. But most senior executives who must assume the sponsor mantle are anything but actively engaged.

At least initially. I call them the uncommitted sponsors!

Senior managers whom we rely on to fill those sponsor roles are busy folks with packed calendars. If they can get something off their plate, they will. Unfortunately, sponsorship can’t be delegated. A manager is a sponsor because of their role in the organization and their overall accountability for a planned change. So, how do we help an uncommitted sponsor become a fully engaged one? With the right kind of questions.

Related Article: Connecting With Your Project Sponsor

In this post, we’ll look at a manager’s journey from habitually uncommitted sponsor to an engaged leader of a transformational change.

Thanks to P.S. for the details on this case.

The Situation

This public sector director was used to initiating changes within her own organization, and achieving outstanding results. Her usual style was to appoint a project manager, have a kickoff meeting with her managers, discuss the reason for the change, the goals she expected to achieve and some boundaries in terms of time, costs and other constraints. She then acted like Captain Jean-Luc Picard of Star Trek fame and decreed “Make It So.”

She usually had no further involvement in the change process, expecting the PM and her managers to make whatever decisions were necessary to deliver the expected results. And for the most part, the approach worked. The changes were generally evolutionary, not transformational. They were usually short-term, low-cost, and low-risk undertakings. The impact was contained within her own organization. The PM and the managers were usually able to make the necessary decisions collaboratively, without the director’s input.

But she was now involved in a change that affected a number of organizations outside her own. She had proposed a transition to Software as a Service (SaaS) offerings to replace a hodgepodge of antiquated, costly and poorly supported mainframe, client-server and homegrown desktop applications that supported her organization.

It was a compelling business case, and her boss had approved the project with enthusiasm. However, he had expanded the scope considerably by asking the director to also include his entire organization, including three other directors and over three hundred additional staff. She realized her uncommitted sponsor role wouldn’t work here.

The Goal

The director’s original proposal, based on her organization’s needs, had been $1.5 million for an application software transition to SaaS services over four years. The payback was an estimated $600,000 annually in cost savings plus projected but unquantified productivity savings in the future. Her boss challenged her to manage the change across his entire organization in the same four years at double the cost, and triple the benefits, arguing that they should be able to leverage and replicate the SaaS solutions in the other groups at minimal incremental cost. His final words: “Make It So.”

The Project

The director realized that the game had changed. But she wasn’t exactly sure how to proceed. Was she still the sponsor? Was her boss the sponsor? Was she supposed to be the project manager? Did she need to recruit a PM? Did she have decision-making authority over the other three directors? What role would her boss play in the project?

The director’s staff had studied the problems and opportunities in her organization over a four month period and had zeroed in on the SaaS solution as the best, most cost-effective long-term solution. They understood the costs, the benefits, the risks and the rewards and were comfortable with the four-year time frame. She had no such insight into the other three organizations.

She arranged a meeting with the other three directors and her boss so he could review his goals and expectations for the project. To her surprise, her boss asked her to describe the planned project. Her boss sat back and watched as her peers pumped her with questions about the impact of the proposed direction on their organizations. Of course, the director could only answer generically. She didn’t know the specifics. The meeting did not go well.

At the end of the meeting, her boss asked her to stay behind. When the other directors had departed, her boss chastised her for running a shoddy meeting, for not being prepared and for not showing the leadership he expected from her. The director bit her tongue and took the abuse.

After the meeting, the director took stock. She concluded she was not the sponsor of the expanded project. That role should be taken by her boss. But he was an uncommitted sponsor. She and the other three directors were targets – managers of organizations affected by the planned change. A plan of action started to take shape in her mind.

The director’s first step was to recruit a seasoned PM who could handle the expanded scope and deal effectively with her boss and the other directors. When he was on board and oriented to the challenge, she and the new PM met with each of the other directors, one on one, to explore the incremental opportunities.

The PM continued the dialogue with the other directors and their staff to establish the overall scope.

There were still lots of questions and issues to be addressed including the priority of the initiative and timing across the four organizations involved. Two of the other directors were also pork-barreling – trying to add additional work to the project to get funding for their pet projects, even though the projects were unrelated to the scope and intent of the original proposal. And then the director saw the opportunity. She would use those outstanding questions and issues to get her boss involved and engaged as the committed sponsor the project needed.

The director worked with the PM to put together a revised project proposal that the other directors agreed with. It was, of course, way beyond the original scope, but that was the point. That would get the boss involved. At the same time, the director met with her boss to start getting him used to the idea of being the sponsor. She told him she and the PM had met with the other directors to put together a revised plan. But, there were decisions beyond her mandate that needed his involvement. Would he be willing to convene a meeting with the four directors to review their plans and make the necessary calls so they could get on with the project? And, of course, he agreed. The meeting happened. The directors presented their plans for their own organizations. And the boss ruled. He established his expectations on priority, timing, scope, costs and benefits. He announced the PM would be reporting to him. He called for bi-weekly review meetings initially, with himself as chair and including the four directors and the PM. And so, the guiding coalition was formed, and an uncommitted sponsor became fully engaged.

The Results

The targets put in place by the director’s boss were to move his entire organization to SaaS platforms over four years, at the cost of $3 million and delivering annual cost savings of $1.8 million. As the PM explored the opportunities across the four organizations and the boss ruled on what he’d pay for, the scope shrank somewhat, costs coming in at $2.3 million and projected benefits at a little over $1 million, still a very good return.

What was as remarkable was the transformation of the affected stakeholders. They went from individual managers battling each other for a bigger piece of the pie to a fully collaborative group focusing on the best value for the entire organization. That transformation was initiated by the director, with the help of the PM. It was brought to fruition by the boss, now an engaged leader, no longer an uncommitted sponsor.

How a Great Leader Delivered

I did a similar post a while ago, For Best Results Use Your Sponsor Wisely, that covered a similar situation with an uncommitted sponsor. Unfortunately, that project ended badly for all concerned. What made the difference in this situation?

In this case, the director recognized that things had changed once her boss expanded the scope of her proposal. She was a change champion certainly, and definitely a target, but no longer the sponsor. She persisted in her efforts to move her boss into the sponsor role in spite of his early reluctance. She presented him with questions that clearly required him to make the calls. She brought in a talented PM to help her manage the transition. She went back to square one with her director colleagues to rebuild their trust and ongoing cooperation.

So, regardless of the change you’re involved with, take a moment and make sure you know what role you’re playing. Also, make sure you know who is filling the other vital roles. And, if you find issues or opportunities, put these points on your checklist of things to do so you too can be a Great Leader. And remember, use Project Pre-Check’s three building blocks covering the key stakeholder group (including the key stakeholder roles), the decision management process and Decision Framework best practices right up front, so you don’t overlook these key success factors. Also, for more on the sponsor role, download the Are You Ready to be a Sponsor pamphlet.

Finally, thanks to everyone who has willingly shared your experiences for presentation in this blog. Everyone benefits. First-time contributors get a copy of one of my books. Readers get insights they can apply to their own unique circumstances. So, if you have a project experience, good, bad and everything in between, send me the details, and we’ll chat. I’ll write it up and, when you’re happy with the results, Project Times will post it so others can learn from your insights. Thanks