Tag: Change Management

Change is Difficult, but Change Management Can Mitigate the Pain

Written by Parvathi Iyer on January 2, 2018. Posted in Articles. 4 Comments on Change is Difficult, but Change Management Can Mitigate the Pain

Ah, the floppy disk. Does anybody even use it anymore?

On the face of it, nobody should be using floppy disks in the 21st Century. Surprisingly, however, parts of the aviation industry still rely on these disks to manage airplane software.

Because airplane software is still distributed via floppies, most older airplanes have these disk drives built in to read and load from the relics. Certain airplane software arrived in sets ranging from 21-48 disks, with a technician loading them one disk at a time on the airplane. This was an error-prone process, and technicians required many hours trying and retrying to get all 21 or so disks loaded without the system timing out. Yet, when it came to eliminating floppy disks and changing it to a quicker, faster way of loading software, the technician’s comment was often along the lines of, “come back in 10 months, I will be retiring. You can change what you want then.” One airline rep commented that they have a stash of floppy disks that would be “wasted” if they transitioned.

Back in the day, a company I worked for decided to put in a new Case Management System, the system to log and manage customer issues and complaints. As a larger computer hardware and software products company, the organization of after-sales customer support represented approximately half the company’s work. It also had an entire eco-system of applications, add-ons, reports, extracts or UDAs (User Developed Applications). The current case management system was something everybody liked to complain about. The main reason for the UDAs was cited as the lack of features and functionality. In fact, replacing it with a newer, user-friendly one was the No. 1 request in a company-wide survey. Still, when it came to replacing it, most users wanted the new system to be exactly like the old one, flaws and all.

The first example is a technology change. The second is an IT system change. The common denominator in both is change. Surprisingly, most technology or IT projects don’t focus on Change Management. The people factor is largely ignored. These projects are run with a small-ish core group of people, the subject matter experts who define the requirements for the project, largely ignoring the vast majority of the people impacted by the project. It’s not surprising, then, that most of the technology projects end up with huge scope creep, or have many issues during roll-out and are inevitably perceived as disasters by the people impacted, sometimes despite meeting all the project goals.

When it comes to work, we are creatures of habit and routine. Most of us take pride in what we do and want to be known for excelling in it. We don’t like it when somebody changes things on us. Change represents a lack of control in some ways, which is why we resist it.

Change works when people feel involved and that they are contributing to the process. It works when people have the time to adopt and internalize the change. As the Project Manager involved in both of the referenced projects, I’ll share a few project management tips that help with managing these changes:

Create the vision

Start with the end state and draw it. And I mean draw. A picture speaks a thousand words. Use this as your reference to communicate the goals, breakdown tasks, report progress. Most people like to see the end-state at the starting point. As the project progresses, people want to see where they are going and how the journey is connected to the end-state. Consistently using the end-state as a reference will reiterate your key messages and also lend credibility to the project.

Plan backwards

Break the end-state into achievable sub-parts or phases. Start with where you need to be and then think of what you need to do to get there. This helps people focus on what needs to be done rather than what is happening now, and also what can be done rather than that which cannot.

Don’t over plan

Be agile. Detail the phase in which you will be spending the most time. Add details to the later phases as you get closer to execution. The reason is three-fold: First, people get obsessed with dates and details and lose sight of the big picture. Second, too many details can cause you to lose the flexibility required to change your plan; Third, people remember dates and hold you to them – it’s easy to lose credibility when you are perceived to be missing deadlines.

Plan for a pilot, a prototype or a user experience focus group

If your project allows for it, start with a pilot. Or create a prototype. Start with a small group of users and monitor their experience. Incorporate the feedback in your plan or product. Agile projects lend themselves to an iterative way of development, where user feedback is incorporated in all stages of product development. However, user experience and feedback can be explicitly included as tasks/events in non-agile projects, if the project demands it.

Advertisement
[widget id=”custom_html-68″]

Communicate, communicate, communicate

Most companies have existing framework and cadence for communications, formal and informal. Find the internal team meetings, the forums, the newsletters, the user groups, the task forces, the internal conferences. Create a project website and update it regularly. Spread the word and then reiterate it again and again through the life of the project. Get feedback. Follow up on questions and comments. This gives people the opportunity to be involved and contribute. Too often the change is too large with very little time for people to adjust and adapt. Early and routine communications give people the opportunity to adjust.

Protect yourself

Yes, sometimes things get personal. Even the best project managers sometimes lose the fight with public opinion and perception. You can be vilified as a terrible Project Manager for the simplest of missteps, real or perceived. Recruit your management to provide air cover. You need an advocate or two who can speak on your behalf and defend you. Bolster your credibility by recruiting the folks with their own street credibility and engaging them in your cause. A few words from them can quiet the worst critic.

Don’t aim for perfection

Accept that you will make mistakes. Build the atmosphere for continuous improvement, for yourself, the project team and the project. Hold periodic reviews or lessons learned retrospectives and use these as opportunities for improvement.

To me every project represents change of some kind. It is important to understand the change and proactively plan to manage the change as part of the project planning.

Note on Change management:

Organizations embark on projects for various reasons: Adding new products, terminating product lines, creating new processes, introducing new technology, ID-ing new opportunities, addressing issues etc. Often, these initiatives require changes to existing processes, job roles, systems. This requires change in how the employees of an organization do their jobs. Ultimately, the success of an initiative depends on how successfully individual employees transition and adopt to the new changes. This is key for any initiative to deliver expected results. Change management should be part of project management. While project management ensures that the project delivers its intended solution, change management ensures that the solution is adopted and used effectively.

From the Sponsor’s Desk – The Great Canadian Payroll Debacle

Written by Drew Davison on December 18, 2017. Posted in Articles. 9 Comments on From the Sponsor’s Desk – The Great Canadian Payroll Debacle

“The beginning is half the whole.”

Pythagoras (est. 569bc-475bc)

Greek philosopher and mathematician

In last month’s post, Start Your Project with PACE, we talked about the need to start projects properly. Projects need the right stakeholders involved and engaged at launch. Those stakeholders have to take a comprehensive view of the planned change and consider all necessary and relevant decisions. They have to be supported and equipped with the practices, processes and resources that will allow them to guide a change to a successful conclusion. And, those conditions need to persist from the get go to the project’s end.

This month’s story, the Canadian federal government’s payroll project, has been in the news for a while now. Unfortunately, it’s another one of those all too frequent multi-million dollar initiatives that didn’t go nearly as well as promised. We’ll take a brief look at what was planned, how the change proceeded and the results achieved to date. We’ll also look at the lesson learned in the hopes that a project failure of this magnitude won’t be repeated, at least by the readers of this blog.

But, before we go on, I have two questions:

Why do we continue to lead projects to failure, wasting millions of dollars, time and opportunity in the process and then conduct audits and lessons learned studies post mortem to determine what went wrong?
Why don’t we, instead, do a pre-check, leveraging the wisdom applied and gained through all those project post mortems, and build our wisdom and insight into the planning and execution of our projects?

Project success shouldn’t be a surprise. It should be planned that way!

Thanks to R.A. for the idea for this story.

The Situation

In 2009, the Canadian federal government decided to replace a payroll system that was increasingly costly to operate and maintain and had been in place for forty odd years. The new system would be used to pay some 300,000 Federal government employees.

The scope was huge. According to a report entitled Government of Canada Transformation of Pay Administration (TPA) Initiative prepared by Public Works and Government Services Canada, there were over 100 different departments and agencies affected, involving 27 collective agreements requiring 9 million annual transactions for more than $20 billion dollars.

Advertisement
[widget id=”custom_html-68″]

The TPA initiative involved two projects. One component, referred to as Pay Modernization, was the implementation of new technology based on a PeopleSoft payroll application. Another element of the change, referred to as Pay Consolidation, involved the reduction of in excess of 2000 payroll advisors spread across the country to 550 staff housed in a new processing center in Miramichi, New Brunswick.

As the Payroll changes were being planned, developed and implemented, three other major changes were occurring across the government; the consolidation of data centers and staff across the country into the new Shared Services Canada organization, Human Resources Services Modernization and the implementation of My Government of Canada Human Resources.

Announced in 2011, Shared Services Canada (SSC) was to modernize, standardize and consolidate IT resources across 43 departments, reducing the number of data centres from almost 500 to 7, consolidating and securing 50 overlapping networks, ensuring all emails were managed through a single common infrastructure, and equipping departments and agencies with updated hardware.

The Human Resources Services Modernization (HRSM) initiative was also launched in 2011. The objective was to modernize human resources services to reduce the number of HR systems to one for the entire government. Included was the implementation of Common HR Business Processes, to bring consistency to the delivery and management of HR services.

My Government of Canada Human Resources (My GCHR), introduced in 2015, was the Government of Canada version of a PeopleSoft Human Resources Management System, which was meant to replace over 70 different HR systems. The synchronization to this new platform was meant to increase automation, standardize and streamline HR processes across departments, increase self-service options and facilitate information sharing. As of June 2017, My GCHR was introduced in 44 organizations and there are an additional 31 different HR systems remaining in operation.

In summary, the government was undertaking a massive change that affected all of its organizations and employees, the related business policies, processes and practices, the underlying technology platforms and interfaces and relationships with its unions and vendors. And it was doing this while other major technology and process changes were occurring.

The Goal

The government’s stated goal was to ensure the long-term sustainability of Government of Canada pay administration and services. When fully implemented, the initiative was to generate savings of over $70 million per year. The total cost was estimated at $309.5 million, $186.6 million for the pay modernization component and $122.9M for the Pay Consolidation.

The Project

The system was called Phoenix. Massively complex, the changes involved 22 different employers – the core public administration plus separate agencies – with over 80,000 business rules governing wages and salaries.

The timeline presented here has been dredged from a variety of sources including government documents, the Auditor General’s report on Phoenix Pay Problems, a Lessons Learned study conducted this year by Goss Gilroy Inc. and a multitude of reports and commentary in the news media.

Spring 2009 – Approved Transformation of Pay Administration (TPA), including two projects Pay Modernization and Pay Consolidation.
February 2010 – Issued request for proposal for System Integrator.
August 2010 – Announced Pay Centre installation in Miramichi, New Brunswick.
June 2011 – Contract issued to IBM for system integrator and PeopleSoft’s Payroll software.
December 2011 – Internal project re-allocation and departmental transfers. The 46 departments to consolidate pay services identified.
Fiscal Year 2012 to 2013:
- Removed funding for change management from the project, to be a departmental mandate.
- Approved Pay Modernization (representing $186.6M of the $309.5M).
- System integrator proposed implementation in 2 rollouts (1 release) versus original plan to launch in 1 rollout.
- Independent review conducted and indicates go ahead to move to Pay Modernization’s implementation phase.
Fall 2013 – Combined Pay Modernization and Pay Consolidation governance committees for TPA.
March 2014 – Office of the Chief Human Resources Officer confirmed that all departments were aligned to the Common HR Business Processes.
June 2014:
- Phoenix design complete.
- Instance of PeopleSoft to be used for Phoenix changed from 8.9 to 9.1.
- Delay in roll-outs of departments moving to My GCHR causing modifications to which departments and agencies were in each Phoenix roll-out.
- SSC experienced delays setting up network connectivity to the Quality Assurance environment for testing purposes.
- Independent review Health Check completed and indicated okay to continue.
December 2014 – Public Works and Government Services Canada signed Memorandum of Understanding with 4 community colleges for professional development programs for compensation advisors.
Spring 2015 – Modified planned July pilot with Natural Resources Canada to become an internal pilot to conduct parallel pay runs for additional reconciliation testing.
Summer 2015 – Deferred functionality enhancements because of timeline pressure
September 2015 – Departments received readiness checklist for Phoenix.
Fall 2015
- Moved roll-out from October and December 2015 to February and April 2016. Moved testing to January 2016.
- Independent review signals things are okay to go live.
January 2016 – Public Service Management Advisory Committee consulted and those present indicate departmental readiness to go live. Phoenix had 109 defects at go-live with none identified as being critical.
February 2016 – First roll-out: 34 departments, 120,000 employees.
April 2016 – Second roll-out: 67 departments, 170,000 employees. Hired 50 resources for telephone support team in Miramichi.
May 4, 2016 – First full payroll from Phoenix for nearly 300,000 employees.

And then the complaints began.

The Results

The Office of the Auditor General of Canada completed an audit of the Phoenix pay problems in September, 2017. Among its findings were the following:

“Overall, we found that a year and a half after the Phoenix pay system was launched, the number of public servants in departments and agencies using the Miramichi Pay Centre who had an outstanding pay request quadrupled to more than 150,000. Departments and agencies have struggled with pay problems since the launch of Phoenix. However, it took Public Services and Procurement Canada four months to recognize that there were serious pay problems, and it took the Department about a year after that to have a better understanding of the problems.

“The problem grew to the point that as of 30 June 2017, unresolved errors in pay totalled over half a billion dollars. This amount consisted of money that was owed to employees who had been underpaid plus money owed back to the government by other employees who had been overpaid.

“In addition, departments and agencies struggled to do the tasks they were responsible for in paying their employees under Phoenix. Public Services and Procurement Canada did not provide sufficient information and reports to help departments and agencies understand and resolve their employees’ pay problems.”

The Goss Gilroy Lessons Learned study is a searing indictment of the project’s conduct. The report summarized the challenges this way:

“It is our view, that it was the underestimation of the initiative’s complexity that led to its downfall. Had the initiative been managed recognizing the wide-ranging scope of the transformation, not limited simply to a system replacement or the movement of personnel, then the initiative definition, governance and oversight, change management, outcomes management, project management and capacity management principles underlying the 17 lessons learned could have been established and closely followed.”

The report goes on to sum up with these thoughts:

“Furthermore, perhaps more important than capacity and capabilities is having the appropriate culture within which to undertake a complex transformation. Agility, openness, and responsiveness are key features of a culture that needs to be aligned with the magnitude and challenge of the transformation.

Finally, in our view, these are lessons that are yet to be learned, not lessons that have been learned through the course of the management and implementation of the TPA. It will be critical for the government to actually apply these lessons in future transformations and more immediately in the transformation challenge currently before the government in addressing the multitude of issues with pay administration today.”

The Goss Gilroy Lessons Learned study found a litany of errors and omissions. A few examples:

The overall management of the end-to-end process transformation was not in place.
No comprehensive plan for transformation of business processes, people/skills, organizational culture, services and functions, quality and timely provision of HR data and related HR systems was ever developed or implemented.
The Common HR Business Processes were not implemented to a sufficiently detailed level in order to ensure government-wide consistency.
One result of the too-narrow scope was an incomplete accountability framework for the transformation. The roles and responsibilities were not effectively designed, documented nor implemented as part of an overall accountability framework.
There was no overall governance body for the TPA as a whole.
There was limited independence of those tasked with the challenge role.
The culture was not open to risk and did not reward speaking truth to power.
Phoenix was not fully tested. In fact, a planned pilot with Natural Resources Canada was cancelled because testing had not been completed. Testing volumes and coverage were reduced in the final stages due to time and budget pressures.

There is much more in the Goss Gilroy report to explain the problems encountered in the Phoenix implementation. Perhaps the most significant finding: failure was built into the project from the start. It didn’t have a chance! Needless to say, it was not and is not yet successful. The project will exceed budget. By how much is yet to be determined. The amount of annual savings is a question mark. Will Phoenix rise from the ashes of this debacle as did the legendary Phoenix of Greek mythology? That remains to be seen.

How a Great Leader Could Have Succeeded

The Goss Gilroy Lessons Learned study provides a terrific framework for rectifying the ills of this particular flawed venture or, for that matter, planning and managing any project. The framework presented in the study includes six major lesson areas and seventeen specific lessons as shown below.

While not as granular as Project Pre-Check’s PACE reviewed in last month’s post, it still covers the essential transformation questions. Had the TPA Initiative used this Goss Gilroy framework at the beginning to address the questions it poses, the project’s chances of delivering a successful outcome would have been greatly enhanced.

Finally, Roger Martin, director of the Martin Prosperity Institute at the University of Toronto, provides some insightful advice about the roles and responsibilities of senior managers in managing transformative change. In a recent article entitled CEOs Should Stop Thinking that Execution is Somebody Else’s Job; It Is Theirs, he states “The common perception is that strategy is done at the top of the org chart, and execution is done below. It is exactly the opposite.” He goes on to suggest that “the things that happen in the activity called ‘strategy’ and the activity called ‘execution’ are identical: people are making choices about what to do and what not to do.”

According to Martin, there is an interconnected cascade of choices in any major change initiative, from the most senior management levels through to first line managers and staff. The information and engagement about the decisions being taken has to flow both ways, from senior managers to reports and back, to ensure the choices fit and reinforce one another. Martin’s advice for managing the cascade effectively?

Make only the set of choices you are more capable of making than anyone else.
Explain the choice that has been made and the reasoning behind it.
Explicitly identify the next downstream choice.
Assist in making the downstream choice, as needed.
Commit to revisit and modify the choice based on downstream feedback.

If such a practice had been in place on the TPA initiative, clear accountabilities would have been an obvious and essential prerequisite. Speaking truth to power would have been an institutional feature. Issues and concerns would have been more eagerly voiced and more readily accepted. It’s certainly more nuanced than the command and control world that existed for most of this undertaking. But it was and is desperately needed.

Oh, and about those two questions I asked at the start of this post, I’d love to hear your thoughts. Thanks.

So, be a Great Leader. Look for and promote decision-making cascades. Use a framework like Goss Gilroy Lessons Learned or Project Pre-Check to answer the critical who, when, what, where and why questions. Put the energy up-front into laying out a route that everyone commits to follow. Keep asking those “beautiful questions” and checking your answers throughout the project. And, put these points on your checklist of things to consider so you too can deliver a successful change.

Remember, Project Pre-Check’s three building blocks cover the key stakeholder group (including the key stakeholder roles), the decision management process and Decision Framework (PACE) best practices right up front so you won’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 – Start Your Project with PACE

Written by Drew Davison on November 27, 2017. Posted in Articles. 7 Comments on From the Sponsor’s Desk – Start Your Project with PACE

Agnes Allen’s Law: Almost anything is easier to get into than out of

If you want to deliver a change successfully, start your project with PACE.

When we have a new idea about a product or service or a solution to an existing problem, the natural tendency is to want to get it done as soon as possible. We tend to think about the desired change as a straight line, from problem or opportunity to remedy. And that’s usually where we get ourselves into trouble. Instead of casting a wide view up front to ascertain and understand the implications, we charge ahead with oblivious tunnel vision. Or, at least that’s what the projects that fail tend to do.

In this story, we’ll look at a cable company’s attempts to deliver an Internet Protocol Television (IPTV) service to respond to their competitors’ offerings, the choices it made and the unfortunate and costly end that resulted. We’ll also look at what it could have done differently to realize a more acceptable result.

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

The Situation

In the early twenty-first century, traditional phone companies ventured into the cable companies’ territory by launching IPTV services. This allowed them to deliver television services to multiple screens – smart phones, tablets, desktop and laptop computers and smart televisions – over their internet networks. That left the cable companies at a competitive disadvantage.

The company in question decided to develop their own IPTV solution rather than acquiring an off the shelf offering. They believed a custom platform would provide a better long term service for their customers, offer the flexibility and agility to keep pace with changing technologies and better serve the appetites of television consumers.

The Goal

Develop and deliver an open-ended, flexible and adaptable custom built IPTV solution by 2015.

The Project

The company launched the IPTV project to great expectations in 2011. They built up their in-house house team and started contracting with vendors to provide the numerous technology elements required for a robust, high performance, competitive solution.

However, the development effort struggled and missed numerous deadlines. The company’s engineering team had to coordinate with over 70 external vendors for a wide array of software, network and hardware components. Over 1,000 people worked on the project, although less than 200 of those were company employees.

Interestingly, in spite of the missed deadlines, progress reports from the numerous teams continued to report green status. Leaders who reported issues were replaced to remedy the problems. The culture became more and more dictatorial, less and less collaborative. And still, deadlines were missed.

As the final deadline approached with an expected launch in the near future, extensive training sessions were offered to those affected within the organization. This exposed the fact that many of the affected departments were not ready. The growing number of defects identified through testing was not being addressed in a timely manner. That meant that the final product could not be shown or used in training sessions. As well, because of the number of vendors involved and their web of relationships, the contract landscape to support such a complex solution was extremely difficult to manage. The Operations teams targeted to support the product did not have adequate time to understand the solution or determine which support contracts to trigger.

And then the plug was pulled!

The Results

Over a year after the IPTV solution was to have been delivered, as they were closing in on the finish line, senior management realized that the solution they had built would not meet the initial business objectives – to be more flexible and agile, to keep pace with changing technologies and the appetites of television consumers.

The solution was so complex that it would be very difficult to support and very laborious and expensive to continue to enhance. They realized after looking at what they had built that partnering with a bigger, more established partner in the space would deliver a higher quality solution with much less overhead.

The company’s board sacked the CEO and cancelled the in-house development effort after five years of work, taking a write down of hundreds of millions of dollars. The company then partnered with an IPTV vendor to deliver a solution by early 2018.

How a Great Leader Could Have Succeeded

Any time we see a sizeable project failure like this, we can be pretty sure that the causes for the costly catastrophe were in place at the very beginning. How does your project avoid that fate? Start your project with a framework like PACE, an acronym for the Project, Assets, Change and Environment domains in the Project Pre-Check Decision Framework. It is powerful, proven and wonderfully productive.

PACE is a checklist with related practices. It presents vital questions for stakeholders to consider, to shape and guide their desired change. If you’re not familiar with the amazing value a well-designed checklist can deliver, check out an earlier post, The Checklist Champion.

What does a checklist do? It asks questions! Matthew E. May, in his article The Power of Asking the Right Questions on americanexpress.com, reviews Warren Berger’s book, A More Beautiful Question: The Power of Inquiry to Spark Breakthrough Ideas. “Berger takes us inside such red-hot businesses as Google, Netflix, IDEO and Airbnb to show how questioning is baked into these companies’ organizational DNA. He also shares dozens of inspiring stories of artists, teachers, entrepreneurs, basement tinkerers and social activists who changed their lives and the world around them by starting with a beautiful question.”

Berger defines a beautiful question as a question that challenges assumptions, that shifts the way we think about something and often sets in motion a process than can result in change. The intent of PACE and similar frameworks is to pose those “beautiful questions”, to ensure, in response to a desired change:

All key stakeholders are identified and engaged
All the relevant decisions are identified and addressed
All key stakeholders agree with the relevant decisions, throughout the project.

Advertisement
[widget id=”custom_html-68″]

Let’s take a look at the four domains – Project, Assets, Change and Environment – and some of the factors that would have been addressed on this project if the project’s stakeholders had used a framework like PACE. Also consider how their inclusion early on could have changed the outcome for the better.

The Project Domain covers the project management parameters to enable effective decisions on time, cost and function delivery. It includes twenty-two Decision Areas within the Planning, Organization, Control and Communication factors. While all of the Decision Areas appear relevant to this project, four in particular are noteworthy: business and technology alternatives, release plan and risk plan.
The Assets Doman includes the people, processes, products and tools that can be leveraged to support a planned project or may require changes for the project to succeed. In essence, the Assets Domain is the supply cabinet to the project world. It includes forty-six Decision Areas within the Resources, Delivery, Project Management, Business Operations, Security Administration, Technology Operations and Infrastructure factors. Again, most of the Decision Areas look to be relevant. Some that would have sparked healthy discussion and debate early on include resource procurement, contract management, management of change, software delivery and technology change. In all cases, the question would be what do we do presently and what do we need to do in the future to manage the upcoming change effectively. Beautiful questions!
The Change Domain encompasses the factors that enable the stakeholders to shape the planned change to deliver a responsive, cost-effective, quality solution that maximizes value. Its focus is to ensure change parameters are fully defined, assessed and controlled in the context of sponsor, change agent and target expectations and capabilities. It includes forty Decision Areas within the Dimensions, Stakeholders, Investment Evaluation and Quality factors. While most of the Decision Areas in this domain are probably relevant to the IPTV project, the key ones include worth (how much the company can afford to spend), phasing and staging, stakeholder roles and responsibilities, the questions around sponsor, change agent and target commitment and capability and competitive advantage and risk.
Finally, the Environment Domain addresses key dimensions of the current state enterprise, the future state target and the business plan that will move the enterprise from the current state to the desired future state. It covers seventeen Decision Areas in the Current state, Future state and Business Plan factors. I expect, if the company had an opportunity to go back and consider this venture all over again, they’d want to address each and every one of those seventeen questions.

The whole point of a framework like PACE is for it to be ever present – to ask these questions at the start to launch the project effectively and to review each decision as the project progresses, as components are delivered and experience gained and as changes (external as well as internal) are assessed and introduced. That discipline ensures decisions are still relevant and appropriate to the current circumstances.

Stop Doubling Down on Your Failing Strategy, an article by Freek Vermeulen and Niro Sivanathan in the November-December 2017 issue of Harvard Business Review offers some interesting reinforcement to the potential power of PACE.

In the article, the authors described why people commit to a strategy, even when it appears flawed. “Escalation of commitment is deeply rooted in the human brain. In a classic experiment, two groups of participants were asked whether they would be willing to invest $1 million to develop a stealth bomber. The first group was asked to assume that the project had not yet been launched and that a rival company had already developed a successful (and superior) product. Unsurprisingly, only 16.7% of those participants opted to commit to the funding.

“The second group was asked to assume that the project was already 90% complete. Its members, too, were told that a competitor had developed a superior product. This time 85% opted to commit the resources to complete the project.

These results underscore the fact that people tend to stick to an existing course of action, no matter how irrational.”

In this story, even though some competitors had implemented IPTV solutions and others were well advanced, the company chose to build their own solution. It took five years and hundreds of millions of dollars before it decided to change that direction and buy a solution instead.

Vermeulen and Sivanathan identify six biases that contribute to these kinds of outcomes; the sunk cost fallacy, loss aversion, the illusion of control, preference for completion, pluralistic ignorance and personal identification. The descriptions are mostly self-explanatory. The biases were alive and well on this project.

The authors present six rules for overcoming these biases:

Set Decision Rules
Pay Attention to Voting Rules
Protect Dissenters
Expressly Consider Alternatives
Separate Advocacy and Decision Making
Reinforce the Anticipation of Regret

Again, the rules are mostly self-explanatory. What’s important to remember is these rules for overcoming decision-making biases are thoroughly enabled by frameworks like PACE. As the authors state, “overcommitted executives are prone to ignore signs of their company’s imminent collapse. That is precisely why companies need to establish organizational processes and practices of the kind we’ve laid out—to encourage managers at all levels to make decisions more objectively and explicitly consider alternative strategies and perspectives.”

While these rules and practices help immeasurably, the most significant condition for a successful project is still the commitment of key decision-makers to deliver on a common vision. Nobody articulates this need better than John Kotter, the renowned Harvard professor, consultant, author and thought leader. His 8 Step Change Model has been used widely and successfully across a range of industries and situations.

If we look at his model (at left), there are three steps that are most applicable to the IPTV case. Step 1 – Create a sense of urgency is tellingly absent from the evidence we have available. Five years to cancellation without any major implementations is not a sense of urgency. Step 2 – Build a guiding coalition across the affected organizations appears to be another significant gap. That helps explain why key segments of the business claimed lack of readiness to implement late in the game. Lastly, Step 6 – Short term wins is all about incrementally building the change. That didn’t happen here.

There is no question that building and delivering an IPTV system for millions of clients is a huge undertaking. By that very fact, it also needed massive due diligence right up front. Fortunately, there are innumerable best practice sources to help lighten the load and ease the journey to successful delivery.

So, be a Great Leader. Use PACE and those “beautiful questions” to start and guide all your projects. Put the energy up-front into laying out a route that everyone commits to follow. Keep asking those “beautiful questions” and checking your answers throughout the project. And, put these points on your checklist of things to consider so you too can deliver a successful change.

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 (PACE) best practices right up front so you don’t overlook these key success factors. Or those beautiful questions.

Rescuing A Project, Part Three

Written by Stephan Bals on November 15, 2017. Posted in Articles. 4 Comments on Rescuing A Project, Part Three

Welcome back to part three of this article. By now customer and Project Rescue Manager have selected each other, the mandate has been signed.

The analysis phase has been ongoing and – by now probably – some people have seriously scratched their heads.

The discovery during an analyze phase is mostly this: some things that have been discovered most of the time show(ed) that very positive willpower was present, hard work has been done and much effort and sweat and tears has been spent getting where the project is now. But somehow, somewhere, things started going wrong a bit, then another bit and it ended up with an avalanche of problems. Some felt or knew, but did not speak out in fear of losing their head. Others did speak out and where silenced, if not sometimes removed literally from the premises. But this is no story about the adventures of Alice in Wonderland. And even in Wonderland, when the queen shouted “off with his(/her) head” it never brought a good solution… This is a story where millions of dollars could be lost for every second that the right corrective actions are not taken. And someone wanted to save the day by digging his or her head in the sand….?

So, now it is time to continue our path to set things (as) right (as possible again). Or maybe not, in case we decide in stage three to kill the project…..
REMEMBER: you may not get all what you originally had in mind when you started the project. REMEMBER also: rescuing a project is about getting still as much as possible of what should be have been delivered, but it will cost you more and you may possibly not reap all the benefits.
You have chosen – in this scenario and for the sake of the flow in this article – that your project should be rescued.

Let us continue along that scenario. We have arrived at stage three: the initial report stage.

3. Initial Report

By now a whole load of million-dollar-questions will have been asked and answers will have been found. Meetings, one-on-one, or one-on-team, meetings with decision makers, meetings with stakeholders, meetings with 3rd party suppliers if involved, meetings, meetings, notes, sub reports per topic will have been written, informally reviewed and discussed. Tons of information and findings will have been assembled and looked in to.

Also, very important, by now the business case will have been revisited. Like I said before: no (valid) business case, no project. I add to that: if the business case has been revisited during the Analyze phase and it is turning out to be no longer valid, be nice to yourself as a customer and kill the project. Unless of course, you have a very good reason not to kill your project even if costs double as much. If so, then document that motivation and make your decision.

You may ask yourself at this point “is it even possible to re-analyze the business case in two to three weeks?”. The question is not strange, especially if you take in to consideration that certain business cases will have taken up to 6 months if not a year to build and get approved.

But it is possible when all work together as expected on their Project Rescue. A process can be followed which was already described in a book by Thiry Michel, PhD., titled “Value Management Practice” (Publish. Project Management Institute, January 1 1997(C), ISBN 978-1880410141).

Mr. Thiry describes this process as a “guerrilla value management analysis” if I remember correctly. During this “guerrilla”-activity a high-pressure cooker environment is formed during which value of activities, moments, environment and so on in the business case are analyzed, or in this case: re-analyzed. All those, from high to low, that needed to be involved where involved.

I mean to say that whilst the Project Rescue Manager has setup his first team to perform interviews and fact-finding, a second team could and should be occupied with revisiting the business case.

The first can feed in to the second set of activities and vice versa, in the end leading to a report and advice on required trade-offs or not, leading to advice if the project should continue or not and if so, to deliver what and why, based upon a revisited business case.

The Project Rescue Manager delivers this Initial Report or Advice Report as it is also sometimes called, to you as the customer at the end of the initial four weeks of work (if no need exists for more time). He/she sends you – his customer – this report whilst at the same time inviting you (the Project Rescue Board members and key stakeholders and members of the research team(s)) to an Initial Report Review Meeting. The meeting should be held within 3 days of you receiving the report. Why? Because time is money and the clock does not stop ticking.

Also, most of the time when you as the customer has received this report you will want time to read it yourself and think about the content and any advice given, and possible devise your own advice and options to present during the meeting, if not send some quick questions on certain items in the report before the meeting. As to such questions: do not expect them to be answered – unless necessary for your view – before the meeting. It could be best for questions to be looked at during the meeting with the rest of the people assembled.

What should be the contents of the initial report? I prefer a short list of items, simply because the discussions during Initial Report meetings can already be very heavily loaded, especially emotionally. Which is also why I ask of all of you involved in such a meeting: stick to business, allow some room for emotion but do not allow emotion to lead you all the way.

The shortlist for discussion items during the meeting or meeting agenda could look something like this:

Lessons discovered; a short history of the project up to now, a list of maximum 10 hot items that need (urgent) corrective measures, the Project Rescue Manager should deliver maximum three suggestions per item and an indication as to the preferred measure to be implemented and justification for such;
Business case review; don’t be nice, but do be honest; politics have created more undesirable situations than honesty has; this topic should give a view on budget, spend per stage vs expected/predicted, burn rates, milestones achieved (on date, delayed, reasons/owner….), deliverables met and capacities achieved and working and which have not been achieved, benefits per stage and achieved or not et cetera
suggestions to go forward, meaning what is still deemed realistic, what deliverables, what benefits per deliverable and capacity, when that benefit is now expected, how high the benefits will be, an overall view of what should be delivered that ties in to the expected outcomes
risk analysis, owners, proposed countermeasures, costs involved, when expected, where expected et cetera
organizational change impact, where, owner
a new plan, based upon the advice of the Project Rescue Manager and his team, depicting the way forward, containing a list of things to do and deliverables to be produced, resources required (human and other), financial plan, renewed benefits plan, et cetera.

The list of items for the Initial Report meeting should not be too long. The meeting itself should not last too long, but it could take up to a week of meetings to crunch all the details. I’ve seen it happen.

All those invited, especially decision makers, should have freed their calendars and make sure they are present.

As to the mentioned draft plan your Project Rescue Manager (and his team) will bring to the table, please note that this plan will still probably have a certain degree of high-level-ness, since we must never forget that a plan is just what it is: a snapshot in time. Further adjustments may be required, as the future unfolds and decisions are made during the mentioned meeting.

But whatever the plan is that gets accepted in the end, we need to remain agile and adaptable to new challenges that come our way, and keep on working as a team on all levels!

4. Evaluate, Adjust, Agree

Your Project Rescue Manager has sent the initial report. You as the customer (project director/owner and colleagues on the newly appointed Project Board) have had your three days to look in to the initial report you received. You have had time to look at it from your different responsibilities and perspectives. You also had time to formulate your questions.

Advertisement
[widget id=”custom_html-68″]

IMPORTANT NOTICE: one thing I may have forgotten earlier on, is very important during any phase during a project recsuce: that is do NOT play the blame-game. Projects are started for many reasons. Some of those reasons maybe subjective (personal interest, wanting to show off how good someone is, wanting to achieve a higher position, suppliers may want to make more money, customers may want to get work done for as cheap as possible). Other reasons may be objective: simply wanting to get a new product in the market because it is useful to all kinds of people, getting more people to read and write by education programs, useful research to reduce the cost of production and delivery of energy, reducing error and costs in a process. Some products may be a mix of both, but still carry good and/or logical purpose and goal(s). But if something goes wrong in a project there can be a thousand and one good reasons for that very project to have gone wrong. Whatever happens, whatever mistakes were made, we should not be dishing out blame. We should learn from what went wrong and we should try to improve on that. Lessons learned are not called for nothing lessons learned.
It is how we humans improve ourselves: by learning, constantly learning. Blaming does not help. It does not make team members better team members, it does not make bad managers better managers. We need to learn what improvement points are, provide training, coaching, guidance. The thing is: if the project failed, all members in the team failed. So, we all need to learn.

I have witnessed those meetings about bad projects as organizer, moderator, coach, project manager and program manager. It simply does not help you progress one inch. If necessary, it can be good to allow for a minute of sarcasm, irony or such. It will never help however if meetings turn in to mud throwing. People leave the table, then the room and the project strands completely …. because no new positive energy can be built and maintained. So, do not blame, but evolve. Do not get angry, get positive. And rebuild. And remember: even rebuilding can mean stopping the project completely, if that is logical. The only people that should be removed from a project are those that caused the problems and are not willing to learn what they can do better. (I said this regularly when during several project rescues).

Having said that, the meeting calendar has been determined and now comes the time to crunch. There is a reviewed and adjusted if not possibly a renewed draft business case, suggestions as to draft scope changes, new draft financials, renewed draft RAID-log, new draft project assumptions, a new draft list of deliverables and capacities these will support, a new draft project plan with stage definitions and milestones, new draft communication plan(s), resource reviews for critical positions and/or complete resource plans and so on or possibly a mix of “old with new”. Whatever the mix is, decisions will need to be made.

The main thing is to decide on the ((re-)newed) business case, deliverables, capacities, benefits and plans. If there is a deliverable that needs to be built that will deliver a certain capacity (e.g. “faster handling of travel bookings by employee, booking department), that will need to be described in the business case.

The business case – in short some more – needs to tell you what is to be delivered, by whom, by when, at what cost and what will be the benefit and over which time that benefit will be achieved in support of what outcome(s). THIS is a business case. Anything else, is just a waste of time and paper.

Any question in today’s project management is and should remain to be driven – in my opinion – by one simple thing: what capacities and benefits will we achieve to support what strategic desired outcomes?

There are some funny things though about business cases…..

Many business cases are seldom of the solid type. Let me tell you another short story. I mean, years back I had a manager, on an internal project, who when asked “how did you build your business case and based upon what assumptions did you arrive at your conclusions and project proposal?” stuck his thumb in his mouth, sucked on it a bit, pulled it out and said “this is how, now do your job”.

I thought to myself “really?”. I declined this gentleman’s project, saving the company at least 1 million $ by declining to accept and execute this project, since having reviewed his business case in some detail I had become convinced it was unachievable.

All I mean to say: business case driven project management (and program management for that matter) is a rarity. And it should not be. The business case should the logical center of focus and drive and passion for the project. The business case is THE leading document. It is however one of the main failure points in project management and program management that is made once, then put away in a drawer somewhere.

Business Cases are usually not reviewed on a regular basis. I have personally seen many customer environments where project management tools are present if not used in abundance. But in most cases I have also noted to my surprise that headers like “Benefits” or “Value estimate” in such tools are almost never used, not kept up to date. Why? Because no one regularly reviews and updates the business case versus the real-life situation.

The business case seems like a “fire-and-forget” kind of tool? Maybe it is more than time to correct on this.

But let us continue. You have discussed with your Project Rescue Manager and the Project Rescue Board members, possibly involving also key decision makers/influencers and change advocates from within the customer organization.

What needs to be done has been analyzed from mountains of information. You have discussed and agreed that stuff needs changing on your project. You need to change your scope to include new features for your deliverables or deliverables need to be scrapped. Your supplier contracts and the way you work with your supplier(s) and quality assurance processes have been optimized. It is now clear how (remaining) delivered capacities will bring more or less benefits via the project rescue efforts. Higher or lower levels of risk may need to be accepted and risk management plans and budgetary risk reserves may need to be changed.

Decision making on what needs to be done, changed, discontinued or otherwise should not be much of a problem, unless anyone has come to the meeting unprepared.

So make your project scope adjustments or whatever kind of adjustments needed. Now.

Time is a wasting and money is a burning.

Maybe a test team consisting of juniors and one medior tester needs to be replaced by a team all seniors, or a product needs to be scrapped because it is no longer has any right of existence.

Decide. Now.

Then, after having decided on what will be adjusted or what will be killed, you give your Project Rescue Manager his/her walking orders and let them get to rework on final versions of all plans, budget, deliverables list, test approach and plans and whatever else needs to be adjusted so that you have the final plan.

One last short review during one last review meeting on final plans and documents, one round of adjustments, then you GO .

We continue in part 4 of this article.

Evolving traits of a project leader in today’s hyper dynamic business environment

Written by Partha Sarathi Ghose on October 31, 2017. Posted in Articles. 4 Comments on Evolving traits of a project leader in today’s hyper dynamic business environment

A. Introduction

The world of business is changing very fast today causing a hyper dynamic business environment globally manifested by market volatility, price fluctuations, political uncertainties, etc.

Such rapid changes in this interconnected world is decreeing a changed order of doing business which, inter-alia includes projects. Consequently, new set of challenges are confronted by leadership at project and enterprise levels needing certain changes the leadership traits. The article endeavours to articulate some important highlights on these global developments and derive certain key traits of today’s leaders.

B. Highlights of areas of Global evolution:

Interconnected global economy: The global economy has become so interconnected that important trends and events in one region can have substantial effects on the opposite side of the globe – for better or for worse.

Political instability and war like situation: Political instability and war like situation, particularly in Middle East inflicting huge political tension and mass movement of refugees.
China’s transition: The transition of China from a period of booming growth to more balanced growth to a slow down and then trying to consolidate, may continue to keep the global market volatile.

Volatility in commodity prices: Tremendous volatility in basic raw material commodity prices

The environmental challenges: Ever growing stringency in environmental norms world over to combat the deadly consequences of global warming and pollution, continuously challenge the prevailing technology in manufacturing, automotive and power generation industries.

Continuous up-gradation of technology: New and emerging technologies for production of new and higher quality products demanding improved technologies.

All these phenomena which basic causes of hyper dynamism, shifting the focus on the attributes style today’s project leader should possess.

C. The key Challenges and possible response:

When summarised, following are the key factors that are prompting so strongly a major shift in project management leadership style:

Extra-volatile market scenario associated with interconnected global economy
Unpredictability of global political environment
Project funding challenges
Socio-economic challenges
Rapid environmental and climatic change
Rapid change in technology

Advertisement
[widget id=”custom_html-68″]

In order to derive the attributes of a leader commensurate with these challenges, we try to analyse the key requirement to deal with each of these factors. Once done, the leadership attributes that can fulfil those key requirements can be identified and prioritised. The issues ascribe certain important and inescapable requirement to deal with them effectively as tabulated below:

D. Evolving leadership traits :

Given the challenges that are faced by the organisations elicited by the rapidly changing world with respect to almost all facets influencing business, the leadership style must evolve with certain essential traits to be acquired by a leaders in this changing time. Derived from the steps in the matrix above, such traits must include but not limited to the following:
Speed: Probably the most important among all behaviours of a leader is ‘speed’, speed to respond to changes the world is experiencing – speed in decision making, speed in project execution, speed in adapting to new technology and speed in reacting to every other aspect that influence the business of the enterprise.

Political and socio-political awareness: Complete knowledge of political and socio-political developments of global significance and those of the regions and localities that could have a negative impact on the project and business must essentially be acquired with the key decisions models essentially taking into account such knowledge and their ramifications.

Team building, knowledge and skill up-gradation: With the technology changing rapidly towards more sophistication, the business and project functions are transforming from skill based to knowledge based endeavours. Some of the low level functions are being taken over by digital technologies like IOT, AI and Machine Learning, robotics etc., completely changing the blend
of people in the team and job profiles requiring the leadership to recast the team blend with appropriate training.

People Management: Consequent upon the changing political and socio-political environments arising out of various changes influencing them, the social behaviour of people would undergo major changes as well. Groups will break and reconstitute. Stakeholder expectations will change requiring very different engagement plans to be in place.

Change Agent: Although it is not necessary that a change agent has to be a leader, but a leader must be a change agent. Especially, with the hyper volatility of various dynamics a business is experiencing in the recent times, a continuous proactive change in strategy is another key trait of today’s leader.

E. Conclusion:

When Alfred Tennyson professed the one line philosophy on change – ‘The old order changeth yielding place to new…’- it is difficult to say today, whether he also imagined the overwhelming speed of change prevalent today. To catch up with rapid changes in all key areas of business and projects, the leader has to have a strong positive will and prepare himself first with certain key attributes of immense importance and then be an effective change agent to yield place to new order of things. The challenge is tremendous and to be the forerunner in this changing scenario, two most important traits that must be adopted inter-alia many other attributes, are speed and pro-activeness to change.

References:
1. Ken Tysiac, October 6, 2016,” 6 global economic trends you can’t ignore”, Link-http://www.cgma.org/magazine/2016/oct/global-economic-trends.html
2. Admin (Nov 7, 2012) Market Vs Economic Cycles and Sector rotation; Link- https://realinvestmentadvice.com/market-vs-economic-cycles-and-sector-rotation/
3. Ian Bremmer (2005), Managing Risk in an Unstable World; Harvard Business Review-June 2005 issue
4. Larry Wynant. “Essential elements of project financing,” Harvard Business Review. May-June 1980, p. 166
5. Bruce Comer (1996), Project Finance Teaching Note FNCE 208/731 Fall 1996 Professor Gordon M. Bodnar