Let’s be honest now. We have all experienced that moment when things go wrong on a project, that horrible moment of dread. Turns out we are not alone.
“According to research by KPMG, an in- credible 70% of organizations have suffered at least one project failure in the prior 12 months and 50% of respondents indicated that their project failed to consistently achieve what they set out to achieve”
~ Hive.com
You can have all the project management training, follow the processes, use the standard templates, but the unexpected can still happen; things will go wrong, especially if the project is complex. It is a fact of project life. But how you manage it is the true test of project management.
“Failure is simply the opportunity to begin again, this time more intelligently.”
~ Henry Ford
Ford has a good point. Having a healthy attitude towards failure and taking the lessons learned from the experience is where your opportunity to fuel future success lies. And although project management is not rocket science (unless you are planning to launch a rocket), it is not easy at times. Allow me to share some of my own turbulent journeys with you in the hope that they may help you with your own project challenges.
We were three days from go-live, waiting for final approval to move SAP SuccessFactors Employee Central, Recruiting, Onboarding, and integration changes to our live systems. As the project manager, I was pleased with myself. The timing was perfect: with the long Easter Bank holiday weekend coming up, there would be minimal disruption to the business, offshore re- sources were on stand-by, UAT was complete, all I needed was sign-off at the phase gate meeting.
I was partway through my presentation when someone asked if I had tested a contractor on- boarding scenario. I had meticulously tracked scenarios and test scripts and saved the evidence, all cross-referenced against scenario IDs for easy checking. I felt sure it was there, but no, I had missed it. ‘I’ll get it tested today,’ I said optimistically. I left the meeting with the agreement that we could go ahead with the cutover as planned if the test passed.
Successful technology relies on people and agility.
The testing went well until the final hurdle. The integration testing had failed! The configuration needed changing and retesting. The developer said it would take at least a week, so the luxury of the long Easter weekend would have been and gone (just like the chocolate eggs). I pulled the project team together for an emergency meeting.
“Get the right people. Then no matter what all else you might do wrong after that, the people will save you. That’s what management is all about.” ~ Tom DeMarco
De Marco is right. Luckily for me, I had a brilliant project team and a great relationship with them and the senior stakeholders. Our budget could absorb the extra work. We soon produced a plan and proposed to the Steering Committee that we use the May bank holiday weekend, freezing the system at lunchtime on the Friday before (most people did finish early on Fridays back then). The offshore team agreed to work longer days to squeeze 4 days’ work into 3.5 days, and as they were ahead of our time zone, the cutover would be completed first thing Tuesday morning with the new system up and running before the business team had made their first cup of coffee.
After rigorous testing, I finally got sign-off, and we went live with minimal issues, thanks to the agility of my project team and the willingness of the business to adapt to the change of plan.
Communication is critical from the outset of a project.
Early in your project I recommend that you include process subject matter experts in the creation of test scenarios. Flag high-risk scenarios and ensure the requirements cover those scenarios. Include subject matter experts in user acceptance testing (UAT) and UAT exit discussions to cover all major points.
You should have a solid communication plan throughout the project. As well as weekly team meetings, establish regular steering committee meetings for escalation purposes. Keep project communications open and honest, so when you hit a snag, it will be easier to deal with. Use phase gate meetings to stop projects moving forward if they are not ready. Be candid. Hiding a problem can make it worse later.
Don’t lose faith when someone cries, “Abort the mission!”
In another case, we had just gone live with an integration from SuccessFactors Employee Central to Active Directory. The team I was project managing had done a great job meticulously following the cutover plan, eagerly awaiting the completion of live system checks when that dreaded email arrived: “The integration is creating thousands of new users – cancel the changes!” This was the one, and only time I had ever experienced a complete failure!
After further analysis, we discovered the live system was slightly different from test. Many employee records had poor data, and some requirements were not identified due to the lack of knowledge of the current systems and processes. The solution was not going to work in the live system. Our choices were limited – abandon the project or start again. A change request was swiftly drawn up for the latter.
Managing stakeholders is a critical project management skill.
Things became increasingly complicated after a new senior stakeholder joined the team. They did not trust the team and insisted on attending every meeting. These meetings became uncomfortable, with conversations constantly focussed on negatives and blame. Mistakes had been made, but they had been owned up to in post-mortem discussions and actions agreed to address the issues. We needed to focus on identifying requirements and solutions. The team became increasingly nervous, afraid to speak up at times. Progress became stilted. This had to stop. I met with the project sponsor and business lead to ask for their support.
We agreed to restrict solutions meetings to developers and business subject matter experts. Senior stakeholders would attend weekly status meetings with the usual summary of deliverables, milestones, key decisions, and achievements as well as key risks or issues. Removing the disruption from solutioning meetings allowed us to collaborate with subject matter experts and develop a new solution, while keeping senior stakeholders focusing on the headlines.
As meetings became more focused on new requirements and what was being achieved, we slowly began to build trust with the senior stakeholder. All stakeholders became more supportive and secured additional resources to sup- port knowledge gaps on current systems. After another round of design, building, and testing the new solution, we finally launched with very few problems.
Developing trust and transparency within the project team.
“To communicate on technical matters, we need only have competence trust in place. This trust will likely evolve as the people who are communicating gain a common language and understanding of the problem to be addressed. The completeness of the communication, elimination of defensive behavior (such as hoarding key information) and willingness to volunteer suggestions will only come as ethical trust is built. It is only then that such communication is seen as safe. If we add emotional trust—typically developed through socialization—we can reach an even higher plane of effectiveness in communication on a project between team members. With these three types of trust in place, and balanced, we have (comprehensive) trust and the potential for highly effective project teams to form and deliver a very successful outcome.” ~ PMi conference paper, “The role of TRUST in project management” ~ Francis T. Harman
As Hartman says, competence, ethical and emotional trust are essential to a successful project. Without trust, communication becomes difficult, people become afraid to participate in meetings; as collaboration breaks down, the team becomes less effective.
In the first stages of the project setup, you should set project guidelines, including code of conduct, the approach for communication, and management of risks and issues. Emphasize the importance of being open and transparent. While you should be practical and realistic regarding problems, encourage a positive attitude towards resolution. Check that you have the right resources and set clear roles and responsibilities. Trust the expertise of the project team. If you are building rockets, make sure you include a rocket scientist.
Inevitably one can expect, “Houston, we have a problem.”
I was project manager for a complex global SuccessFactors LMS implementation. We had just gone live with over a million records mi- grated, thousands of courses imported, hundreds of e-learning courses uploaded. My next project would not be starting for some time, so I agreed to take on a support role, to support end- users and learning administrators in the central Learning and Development team and the business learning teams. Backed up by the internal HRIS support team and a third party for more complex tasks. What could go wrong?
It was just a few days after go-live, when suddenly I was inundated with Helpdesk tickets, receiving two hundred in one day and numerous requests for help from the administrators. I was rapidly becoming a bottleneck. Most of the issues were simple – e-learning pop-up blockers and browser settings, all of which were covered in user guides, but people were not using the guides. There were other issues regarding access, missing records, and courses. And the business learning administrators needed help – they could not remember how to do tasks. The pressure was increasing. Our Service Level Agreements were off target. It was like trying to land on the moon, but only getting as far as the International Space Station. Our customers were not happy, and I was miserable. We needed to escalate now!
We arranged an emergency meeting with the key stakeholders and subject matter experts and laid our cards on the table. After many discussions, we agreed to split the work. Shared services would pick up general queries (with a guide to support them). This relieved the pressure significantly. The guides were simplified. Additional training was given to business learning teams and their system access was expanded so that they could become self-supporting. Over time more experienced resources joined the support team.
A change management strategy is critical from the start.
At the beginning of your project, agree upon a change strategy aligned with your business culture. You should assess changes. Who and what will be impacted, and what support will be required post go live? Involve business process experts and get them to clarify processes, identify change impacts, and share their inputs in test scenarios and training. Allow plenty of time for training ahead of go-live.
Change champions from the business can be great advocates for change, encouraging and supporting their colleagues through the change while providing valuable insights to your project. Get them involved from the start. Invite them to design meetings to understand why the process/system was designed that way. Train them and involve them in testing.
Ask them to review support materials. Ensure you assign resources with the right capabilities, capacity, and decision-making power. Be wary of wear- ing too many hats at the same time. It is difficult to balance multiple roles and responsibilities, especially if you have conflicting priorities.
The eagle eventually landed – and we added lessons learned to our documentation.
Well, we finally got there in the end, despite the turbulence, and with the benefit of hind- sight, it is easy to see where we went wrong. If you capture risks along the way and revisit them throughout the project, this can help you to fend them off before they become issues. Flag high- probability risks in weekly meetings and monitor them regularly. Look at both positive and negative lessons learned from similar projects before starting. Speak to other project managers. Add them to your support network. They can help you identify key watch outs and be a great source of ideas and a neutral ear to turn to for advice.
Let’s face it, you will likely experience many small failings throughout a project; we are all human after all. And while you cannot avoid failures altogether, you can look out for early warning signs, e.g., unclear requirements, lack of skills, knowledge, delayed deliverables, team stress levels. Make sure that you look after your well-being and watch out for others. If you need help, ask for it.
If you keep a healthy attitude towards failure and heed lessons learned, you can grow stronger and more resilient. And don’t be afraid to share your failings (and successes) with others. You never know, they may get you out of that tailspin.
