Tag: Facilitation

Plan for the End Game

Written by George Pitagorsky on October 20, 2015. Posted in Articles. 6 Comments on Plan for the End Game

All too often project managers fail to plan adequately for the end of the project. Not planning for what happens when a product is released leads to problems and makes a successfully developed product look as though it is a failure. Worse, it puts business continuity and customer confidence at risk.

While IT applications are one example, the same principle applies to any product. When the product is a commercial product, consider the needs of the sales force in addition to the users, trainers, and support staff.

Change is Unpredictable

The main principle is that the implementation of a product is a change event, and that change is predictably unpredictable. When a new product is implemented and deployed it impacts its users and support staff. The first users of the product will have questions. Users will report errors. The questions must be addressed, and the reported errors investigated, responded to with work around solutions, or other information. If there are product defects, they must be addressed. Defects may be in the core product itself or in its documentation or training materials (which are part of the product).

When rolling out computer applications, the concept of hyper-care is applied. Hyper-care recognizes that any time a new application or major change is released, there is need to plan for a high incidence of support requirements. Support will be needed by the users and also by the normal support staff. The product is new to both of them. The users will turn to the customer support staff for support, and the support staff will turn to technical support. Technical support, if they are not the developers, will turn the developers, who may be busy developing other products.

Planning Requires Consideration

Addressing deployment issues requires clever planning. Clever planning takes managing the end game into consideration and allocates the time, resources, and money to make the new product release a success. This seems so obvious that writing about it seems unnecessary; yet, I have run across a number of recent incidents in which experienced project managers and their managers and clients have found themselves in unfortunate situations. They failed to plan adequately for hyper-care and have failed to adequately prepare users and support staff.

In one case, a firm contracted an organization to develop a product but left out of the contract any mention of knowledge transfer to the in-house IT staff that would support the product. The vendor’s staff was to be finished with their work upon acceptance of the product. Acceptance of the product was achieved when the product testing was completed. Full deployment of the product was planned for a fixed date that kept getting closer as the testing progressed.

Related Article: Agile Chartering: Beginning With the End in Mind

The outcome was that the in-house IT team had to scramble to learn the product, without formal support from the vendor. They needed to be able to address bugs and answer questions and issues that the customer support help desk staff could not answer. Since there was little training for the customer support staff, there were many such questions and issues. Customer support was also supporting other products and became overwhelmed with calls. To make things worse, the in-house technicians were scheduled to work on other “priority” projects and had no time formally allocated to the “hyper-care” activity. This, of course, led to high-pressure and a choice between delaying the other projects (even with overtime work) and not supporting the new product. With high-pressure came stress and that resulted in arguments, finger pointing, and dissatisfied users.

This scenario is not limited to vendor based engagements. The same thing happens when the product is developed in-house, and there is poor end game planning.
The cause of this scenario was short-sightedness. Project managers that focus on the development of the product and fail to consider how that product will be deployed and supported are not addressing the entire project. This is often the case because the project manager is a technical person who is expecting someone else to take care of things once the product is delivered. There is a hand-off implied. Development is complete; deployment is someone else’s job

If there is someone else accountable to hand the product over to, then they will make sure that users are trained, and customer support staff is adequately prepared. They will make sure that the end game is part of the overall project plan.

But who will make sure that the developers pass on their in-depth technical knowledge of the product to the technical team that will maintain it and troubleshoot? Even if the development team retains the technical support role, will they have the time to do it or will they be thrashing between new development and technical support activities, particularly during the early life of a product? Will the technical knowledge holders be there forever? Will technical product development people be motivated and capable of transferring their knowledge or will they need an intermediary to debrief them and pass the knowledge on in a structured training? Will there be a clear understanding of the need for support and the number of hours it might require by customer support and technical support people?

Don’t Be Shortsighted – Plan for the End

Don’t be shortsighted. These and other questions should be asked and answered when initially planning the project. The hyper-care effort, documentation, training, and knowledge transfer are part of the project, not something that gets dumped on the business and operational groups that support the product.

End game planning requires that the following are addressed and included in the project plan:

Formal allocation of “level 3” support by the development team to the technical support team
Formal allocation of “level 2” support by the technical support team to the customer support team
Formal allocation of additional “level 1” customer support staff for the hyper-care period
Structured training to transfer knowledge to technical support, training and customer support teams
Technical and user documentation that reflects the true nature of the product
Structured training for the users
Pilot rollouts to make sure that the product and its training and support work in the real world
A contingency plan for the possibility that the product fails to perform adequately and must be pulled from production
Expectation management to prepare everyone for the real world of implementing a new product. No matter how well people have been trained and how well the product has been tested, there will be bugs, problems, and misunderstandings, all of which can be handled if you are ready for them.

From the Sponsor’s Desk – Even Project Managers Sing the Blues

Written by Drew Davison on October 19, 2015. Posted in Articles. 5 Comments on From the Sponsor’s Desk – Even Project Managers Sing the Blues

Let’s be honest. A project manager’s authority typically revolves around how to deliver a planned changed to the sponsor’s who, when, what, where and why dictates. When a sponsor doesn’t make an essential call on a project issue, the PM can be left in limbo.

In this case, over a three-year period, the project in question went from a top corporate priority to an important project, to just one of the many things that had to get done. Sponsor passion for the endeavour went from sizzling hot to ice cold. The PM’s ability to get key decisions made followed the same pattern, from immediate to never. What could the PM have done differently? We’ll see.

Thanks to G.D. for the details on this case.

The Situation

This financial services organization was experiencing a decline in the rate of growth for a key product line. The products in question were administered with largely manual processes. They were slow, error prone, and costly. The company’s potential customers were turned off by the whole exercise. As well, some their competitors had solutions in place to capture, evaluate, and respond with a timely decision, in many cases in real time. With these other appealing options available, the company was losing business.

The VP of Administration (VPA) attributed much of the decline to the slow, cumbersome process of capturing the prospect’s information and the failure to provide a timely decision. With the executive committee’s support, the VPA launched a project to automate the evaluation and approval process.

Related Article: Best Practices Accelerate Value Delivery

The Goal

The VPA’s goal was to reduce costs, improve service, and increase sales through a streamlined capture, evaluation, and approval system. His initial target for real-time approval was 20% or more of the submitted applications. He wanted a solution implemented within twelve months with a target return on investment of 25%.

The Project

The VPA and the CIO discussed the project’s leadership needs and selected a contract PM that had worked for the organization before and had shown an ability to get things done on a number of different fronts. Given the urgency and tight timelines, the PM’s first challenge was to assess the available alternatives and select the best one to achieve their goals.
The target solution would affect the sales organization as well as the administrative staff so the PM called on the VPA, the project’s sponsor, to meet with the Sales VP to get his backing for the endeavour and provide the needed resources going forward. The Sales VP was familiar with the challenges the company was facing and fully supported the project. He promised to participate in the steering committee with the VPA and CIO and provide timely decisions as the need arose.

With the senior executives lined up and on side, the PM and his team proceeded to build the assessment criteria and identify and assess the available alternatives. The VPs had provided the requested subject matter experts. They were experienced, motivated and passionate about solving the problems they had lived with for far too long. In two weeks, they had an assessment criteria draft ready for review by the executives. It was turned around in two days with some minor adjustments. Two weeks later they had five possible alternatives identified including an in-house developed solution, one cloud solution, and three competitive software packages. After a half day review with the VPs, the list was cut to three options. The in-house solution was dropped along with two of the packaged software solutions.

The PM and his team went to work assessing the short list alternatives. One option rose to the top. It seemed to have the best functional and non-functional coverage and the greatest potential for early delivery. Again, the team reviewed their findings and recommendations with the executives in a half day session and emerged with a decision. They would acquire a software package that appeared to cover most of their needs, could be implemented in three stages (a couple of back end, administrative components and a web based front end), and had a good track record. The only challenge was the price. It was the most expensive.

The PM brought in the manager of Contracts in IT to negotiate the contract with the vendor. Because of the target 25% ROI, the Contracts Manager suggested a fixed price contract as a means of controlling potential cost escalation. The selected software vendor worked through a systems integrator (SI) so the discussions took longer than planned but in the end, a deal was reached. The contract was signed by the VPA and CIO and the real work began.

The Administration and Sales subject matter experts defined the new business processes, evaluated the chosen solution against those needs and documented the changes required. The turnaround from the SI was terrific, and the first back-end component was implemented successfully in six months. The same approach was used for the second back-end component. However, turnaround slowed dramatically. The SI maintained that the development budget had been consumed, and they were now restricted to the annual support amount specified in the contract. Of course, the PM had kept a close eye on costs and resources and was surprised by the SI’s claim. It turned out that the SI was adding a 25% overhead charge to the direct labour costs. The contract was not clear on the matter, and the SI refused to budge.

The PM approached the VPA for addition funding. His team had put together a business case that demonstrated the incremental funding for the second stage enhancements would still support the 25% ROI target. The sponsor indicated he’d review the plan and get back with a decision. Unfortunately, the sponsor was wrapped up in other priority initiatives and the reply didn’t come for six weeks. That put the twelve-month implementation target out of reach. The same challenges persisted with the third stage web front- end. Changes required by the business were prioritized and queued, and the SI nibbled away using the limited annual support budget. Appeals by the PM and affected management in the Administration organization were rebuffed or ignored outright. The sponsor had other priorities on his plate.

The Results

During the first stage work, the steering committee met monthly. The project progressed smoothly, and there was little need to engage with the executives beyond the monthly meetings. After the first stage implementation, the steering committee stopped meeting on a regular basis. When progress slowed because of lack of funding, the PM dealt with the sponsor. The CIO and Sales VP were essentially out of the loop.

The project took over three years to implement fully. Cost reduction, service improvement, and increased sales targets were mostly realized, but months or years later than planned. Even the realized ROI was close to target, at 21%. Timely decisions on the incremental funding required would have boosted the benefits significantly.
In the second year, the PM became totally frustrated with the drop in priority and lack of progress on funding approvals and resigned. Even project managers sing the blues, on occasion.

How a Great PM Could Have Improved the Outcome

The PM had a great financial case for additional funding, but he didn’t have the authority to make the decisions. Only the sponsor could bless the incremental expenditures. And the sponsor’s attention was directed elsewhere. It’s a difficult situation. But the PM had a couple of options:

Executives usually have overloaded plates and overbooked calendars. That can easily create an “out of sight, out of mind” condition. The challenge for this PM, for all PMs in fact, is to make sure your project always stays “top of mind”. That is the only way the organization to going to recoup those project expenditures. How do you do that? One way is to use a Decision Framework (use Project Pre-Check or create your own) and monitor key stakeholder satisfaction at a more granular level, on an ongoing basis. That cements continuing engagement.
Keep those steering committee meetings going. If attendance starts to drop off, change the content so the attendees will get value and provide value in return.
The PM could have worked with either or both the CIO and Sales VP to exert additional pressure on the VPA. The Sales VP especially had a vital interest in seeing the problems rectified. At the extreme end, if the CIO and Sales VP were on side but their entreaties ignored by the VPA, the PM could have encouraged them to engage the CEO. After all, the project was a corporate priority when it was launched.

Sponsor attention is vital but not always present, as in this case. So, if you find yourself in a similar situation, think about how you’re going to ensure ongoing commitment and engagement from your key stakeholders. Also, be sure to put these points on your checklist of things to do in future endeavors so you too can be a Great Leader. And remember, use Project Pre-Check’s three building blocks covering stakeholder, the decision management process and Decision Framework best practices right up front so you don’t overlook these key success factors.

Finally, if you have a project experience, either good or bad, past or present, that you’d like to have examined through the Project Pre-Check lens and published in this blog, don’t be shy! 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

Leadership Lessons – Five Ways to Build a Box

Written by Peter de Jager on September 8, 2015. Posted in Articles. 6 Comments on Leadership Lessons – Five Ways to Build a Box

Despite the classic status of the quote “Think outside the Box”, it contains a subtle flaw. As a description of what the creative process is all about, it’s a brilliant distillation of the basic concept “think differently.” However, as a recipe for being creative, this famous quote is a dismal failure. A standard response from someone hearing it for the first time is… There’s a box? What box?

As an example of this response in action, consider the following little exercise. Separate your group into teams of 2-3 people and hand each team a new deck of playing cards. Instruct them to build on the table in front of them the tallest tower possible in five minutes. During this time they may not ask you any questions.

A typical team will manage to create a tower one card high, an extraordinary team might deliver a tower three cards high, and every now and then a genius team will emerge. They’ll build a tower 10-15 cards high. They’ll do it by forgetting that they’re playing with cards and instead, realize they’re playing with stiff pieces of construction paper, perfect for bending, tearing and mutilating into perfect paper building blocks.

Those that don’t escape from the constrictions imposed by the label of “playing cards” fall into two distinct categories; those that never even think of bending or tearing the cards and those that do think of this, but hold back because “you don’t bend or tear playing cards”. The latter group is at least aware that they’re constrained in a “box” defined by the rules for handling playing cards. The former group is oblivious to the box around them. A box that is, for the most part, self-imposed.

The advice “think outside the box” requires that we’re aware of the boxes surrounding us. A good step in that direction is recognizing that many of those boxes are self-imposed and that we can identify the behaviors that erect some of those boxes. Here are a few common self-constraining thought processes.

We don’t listen to our own wisdom.

As a consultant the most common problem presented to me for a solution is best summed up in the following client statement, “Peter, it hurts when we do this…” When faced with that problem statement it’s tempting to respond with the punch line from the child’s “Dr. Dr.” joke… “Then stop doing it!”

The fact is that we know how to solve many of the problems that face us. All we need do is accept that our existing behavior is not resulting in the desired outcome, and there we should find another course of action. The box is endlessly repeating an action we know doesn’t work.

We don’t listen to the wisdom of outsiders.

The “not invented here!” syndrome is endemic. The irony is once again that we recognize we’re unable to get out of our rut of thinking, yet we resist any injection of an external idea. The box in this instance is a double box. At the first level, the box is a lack of an internal solution. On the second level, the box is the notion that to protect our ego we must reject external suggestions.

Only those from out of town possess wisdom.

This is the exact opposite of the one above. There’s a strongly held belief that unless you’re from far away you can’t possibly have a solution to a local problem. It’s as if geographical distance bestows wisdom on the person giving advice.

Now I don’t want to totally eradicate this notion as I make my living being the “out of town expert”, but the reality is that the person sitting in the cubicle next to you is just as likely to have a solution to your problem as the jetlagged talent from seven time zones east of you. Frequent flyer miles do not boost IQ.

The simple isn’t complex enough.

We demand that our solutions are complicated and costly. If the problem has posed great difficulty in the past, then the solution cannot be simple. The reason for this is itself simple enough. If the solution is simple, then we must be at fault for not discovering it ourselves. We insist that solutions to our persistent problems be complicated and costly to protect our egos.

Here’s a simple example from the allegedly complicated world of organizational ethics.

If you’re willing to have your actions published on the front page of the Globe and Mail, then your actions are likely ethical.

Now, that’s not a perfect solution to most ethical problems, but it solves the vast majority of ethical issues.

Repetition devalues Truth.

This one is closely related to “simple isn’t complicated enough”. The great truths, the classical answers are often considered clichés, “Do unto others, as you’d have them do unto you”, “To thine own self be true”, “Look before you leap”, “Think globally, and act locally”. These are all simple, commonly repeated phrases. Just because they’re common doesn’t, or at least shouldn’t, degrade the wisdom they contain.

All of the above thought traps restrict our problem-solving ability. By needlessly constraining how we see the world, they limit our ability to think our way towards solutions. The irony is that these aren’t imposed on us. There’s no one to blame for ourselves, and that brings to mind a sixth box building strategy – we’re seldom ready to consider that we’re the source of our biggest, most intractable problems.

Strategies to Keep Your Project On-Track

Written by Lisa Anderson on August 21, 2015. Posted in Articles. 7 Comments on Strategies to Keep Your Project On-Track

As easy as it seems to keep a well-planned project on-track, it isn’t! In working with hundreds of project teams over the course of my career, I’ve found that projects do not fail in formulation; they fail in execution. The best results follow those projects that are well-managed and kept on-track. Results are not just substantial in terms of monetary gain, but are also important to customer satisfaction and loyalty. In today’s Amazon-impacted marketplace, a leg up on the competition can be a vital competitive strategy. What are you doing to ensure success?

There are several powerful strategies to keeping a project on track. Some of the most impactful are as follows:

It starts at the top: As with success overall, keeping your project on track starts at the top. Leaders can make or break success. Thus, selecting the best project manager is key to success. Of course, it is beneficial also to have the best project sponsors and executive support; however, the 80/20 of success is putting the right leader in place.
Put time in upfront to understand the project plan: Although it is a common desire to jump into the project and start performing tasks, it is significantly more successful to take the time to develop a strong project plan. Make sure to coordinate with all relevant parties and incorporate input. Ask questions and consider potential issues. Be clear on your plan, and results will follow.
Focus on the critical path: One of the secrets to success relates to focusing exclusively on the critical path. It is easy to get deterred on all the project plan tasks as they all seem important; however, the most successful projects consider the 80/20 as the critical path. In essence, the focus is on the tasks that are most likely to hold up the project from progressing at the optimal pace and those which are likely to impact whether results occur.
Follow up with task owners: Following up with task owners can ensure success. I’ve found that a quick check in with task owners to remind them of upcoming tasks, especially critical path tasks, can be invaluable to making sure the owner is prepared to start on time and that they have the resources available to successfully complete the task. Ask if there are any concerns and work to address them prior to the start date.
Embrace project supporters: Whether a project sponsor or a peer to the project team, project supporters are integral to project success. Identify project supporters and keep them in the loop. Make sure to provide information so that they understand how they help to contribute to the project success. Make it easy for them to support your project.
Celebrate successes: An important part of any project is to celebrate small wins along the way. Don’t wait for the project to be completed to celebrate success. Success breeds success. Find people doing right. Look for indicators that the project is moving in the right direction. Recognize the progress and celebrate the contributions of the team.
Simplify: Complex project plans do not deliver success. Contrary to popular opinion, I’ve found that more often than not, success stems from simplification. Simplify to the tasks required to deliver your end result. Avoid complexity. It will become easier for the team to understand and execute.
Monitor metrics: Do not wait until the end to evaluate project success. Identify milestones. Keep an eye out for critical path milestones. Monitor progress towards these milestones. For the critical milestones, develop interim checkpoints so that you can monitor progress along the way. That way, you’ll have the opportunity to adjust as needed.
Don’t take your eye off the prize – results: Although it is easy to get caught up in a maze of tasks and to-do’s, don’t take your eyes off of your desired end results. Keep them in mind and focus on those actions that will contribute specifically towards delivering end results.
Communicate, communicate and communicate: Just as in real estate where location, location and location are the three most important attributes of a new house, communicate, communicate and communicate are the three most important attributes in keeping your project on track. If all team members, supporters, sponsors and other related parties are not aligned, the project is likely to veer off track.

Since executives count on projects to deliver the vast majority of improvements to company performance (such as growing the business, increasing margins, and accelerating cash flow), keeping the project on track is essential. Those who follow these ten strategies will succeed significantly more often than those who don’t. Why take a chance on what’s vital to business success?

From the Sponsor’s Desk – Success in the Cloud

Written by Drew Davison on August 11, 2015. Posted in Articles. 3 Comments on From the Sponsor’s Desk – Success in the Cloud

Making sure key business processes and technologies are aligned to an organization’s strategic directions is almost a pre-requisite for survival these days. When upgrading those core services, a cloud solution is often in the mix. But a move to the cloud has been a risky and disruptive experience for some.

In this case, we’ll see how a CFO and her Controller managed a transition to a cloud service to transform the business and supporting operations. The project was a resounding success on all fronts. How did they achieve that result? With the help of some tried and true best practices.

Thanks to D.M. for the insights on this story.

The Situation

This medium size international consulting organization had outgrown its key back office processes and technologies. The ERP/financial application was out of support and upgrading to current levels was problematic. The CRM software was not well integrated with other systems and was little used. In addition, there were many manual processes, reporting and analysis capabilities were severely limited and business needs had outgrown the existing functionality.

The CFO was frustrated by the limitations imposed by the existing processes and technologies. She knew the CEO and other senior managers echoed her concerns. The organization had acquired a number of companies to expand its reach and add additional services. It would continue to do so. It needed streamlined business processes supported by an adaptive and expandable technology infrastructure to match its growing demands.

So the CFO, with the CEO’s support, launched a project to design, build and deliver the processes and technologies the organization would need to support its strategic plans going forward, including:

Revenue growth
Profitability growth
Geographic expansion
Improved productivity
Improved cash management
Improved forecasting ability
Improved innovation
Scalability

The Goal

To deliver business processes and supporting technologies that supported the organization’s strategies and provided the following capabilities:

Seamless integration of CRM and financial information
Process automation
Flexible reporting
Dashboards for the CEO, CFO, senior managers and customers
Simple acquisition integration
Enhanced security
Remote access
Multi-currency and multi-language support

The CFO targeted a 30 month transformation project, to be delivered in six month stages based on business process priorities and assessed risks. Total costs were not to exceed $2.4 million. That would provide a 25% return on their investment with some very significant intangibles enabling the company’s growth strategies.

The Project

The CFO’s first move was to appoint her Controller as the Project Director (PD) for the duration of the undertaking. He knew the challenges and the opportunities and had prior experience managing transformational initiatives with other organizations. The CFO also formed a steering committee with herself as chair and project sponsor and including IT and the business owners. Their primary role was to advise the CFO and the PD. They were also to act as a decision-making body for any issues that could not be resolved independently.
With input from the company’s executives, the PD pulled together a project charter that presented the project’s goals, identified the key decision-makers and their accountabilities, specified the processes, functionality and technologies and the related needs that had to be addressed in support of the organization’s strategies. He also established project priorities, risks and mitigation plans and included a high level phasing plan that responded to the scope, priorities and risks within the budget and time constraints dictated by the CFO. The charter was fully blessed by the steering committee.

The PD recognized that the technology selected would be a catalyst and enabler for the reengineering of the targeted end to end processes and so planned for a first release that included the technology assessment, acquisition and implementation with one priority business process.

The PD conducted interviews with each of the key stakeholders to determine their organization’s needs going forward. From those interviews a fifty-four factor decision framework was developed. The framework focused on the total cost of ownership and addressed four categories: operations, security, strategy, and financial. An RFP went out to two current vendors, one additional vendor of in-house managed software and two cloud based SaaS vendors. Each vendor’s submission was assessed numerically based on the decision framework. The winning vendor offered a cloud solution that was being used by a sizeable number of organizations, all with nothing but good reviews for the SaaS solution and its vendor.

With a vendor and a solution selected, process reengineering proceeded according to plan. Implementation is the key to any system’s successful life cycle. In this case, the implementations were actively monitored and upgraded in order to maximize its effectiveness. Business owners were held accountable for maintaining their areas of the system. The Helpdesk process was put in place from day one, with escalation through to the vendor. Finance and IT met monthly to review issues and requests from users. Adding and revising functionality was ongoing. Finance and IT representatives also met monthly with the vendor consultants to ensure they were all aligned.

Perhaps the most important project directive was to use the core application functionality unless it violated company standards or the law of the land or impeded strategic initiatives. That streamlined and accelerated the decision-making process around requested changes. It also kept their implementation very close to the standard offering, making it much easier to accommodate future solution upgrades, whether to fix bugs, improve security or functionality or add new features.

The Results

The project was closed after three and a half years, 40 percent longer than the 30 month target. The additional time was authorized to take advantage of additional functionality offered by the cloud solution that was not originally included in scope. The decision to extend the project was fully endorsed by all key stakeholders and yielded substantial incremental savings. The project cost was well below the $2.4 million target, coming in at $1.75 million. Ten releases were used to deliver the full functionality, averaging 3 to 5 months each. The shorter releases were enabled by the extensive functionality and flexibility of the chosen solution. The shorter, more frequent releases also helped build the organization’s ability to engage affected staff and instill a continuous improvement mindset. Release quality from inception was outstanding. Return on investment was a sterling 43%. Needless to say, the key stakeholders were thrilled with the results.

How Great Leaders Delivered Superior Results

The foundation for success was built by the CFO, starting with strategy and executive endorsement and establishing clear goals and boundaries. While there was significant technology involved, she made it clear from the start that this was a business project. The PD leveraged that foundation, entrenched the decision-making accountabilities of the key stakeholders and focused on technology as the enabler. The best practices that contributed to the project’s success:

This was a business project. The key stakeholders were actively involved in the process designs affecting their areas and in the technology assessment and selection. They also played a more holistic role through steering committee membership.
Evaluation criteria were established in collaboration with the CFO, IT lead and business owners to ensure a comprehensive solution assessment process. It also helped entrench key stakeholder buy-in.
The CFO was adamant about acquiring the right people with the necessary knowledge, skills and experience, starting with the PD.
They were smart about leveraging the technology and the in-place team to deliver incremental value. Sure, the project lasted 40% longer than planned but they used that time and talent to deliver greater returns from opportunities that weren’t obvious when the project started.
Processes were adapted to the technology platform whenever possible to reduce costs and increase flexibility and responsiveness.
A phased implementation was used to reduce risks and accelerate value delivery. Data conversion (scrubbing, formatting, loading, sequencing), integrating and interfacing with other systems and development of custom functionality were staged as needed to support release content.
Clear guidelines were established for the approval of change requests and the addition of functionality to the cloud solution.
The use of automation was maximized, including inputting data once at the earliest point.
Change management was a significant focus to overcome resistance. Multi-way and multi-form communications and executive acknowledgement and support played an integral role.
All users affected by the change were involved in the change. They were called upon to help design and test the new processes and technology interfaces, and so they became part of the solution, not part of a problem.
Scheduled training was offered as close to Go-Live as possible and was a pre-requisite to get access to the system.

The CFO and PD chose a smart and responsive approach to supporting the organization’s strategic aspirations. It delivered value in the short term and provided an enabling legacy for the long term. What more could one want? So, please, put these points on your checklist of things to do in future endeavours so you too can be a Great Leader. And remember, use Project Pre-Check’s three building blocks covering stakeholder, the engagement and collaboration process and decision area best practices right up front so you don’t overlook these key success factors.