From the Sponsor’s Desk – Luck Has Little to Do with Project Success!
“Luck is what happens when preparation meets opportunity.”- Seneca
Sometimes, things seem to fall nicely into place. The potential major risks we identified didn’t materialize. The executive sponsor was actively involved, got the funding and made the decisions when required. The resources we needed were available when we needed them. The team members jelled and thrived. Our customers were enthusiastic partners. The vendor delivered on its promises. It seemed we lucked out. But, of course, we know that luck has little to do with project success!
In this post, we’ll follow the journey of one technology consulting company through three distinct, ever more challenging projects with the same client. We’ll see how relationships, professionalism, capability, insight and superior service helped the company earn its opportunities and create its own luck.
Bill Moher is an Information Technology executive and consultant, with experience in marketing and sales, architecture, software development and operations. One of his sales people was attending a weekend wedding and, as one normally does at such events, he chatted with the other guests at the reception. He was intrigued with one guest in particular, the CEO of a financial services organization. When the sales person explained that he represented a technology consulting firm, the CEO’s eyes focused in and he said, “Perhaps you can give me some advice.”
The CEO went on to talk about a problem his company was experiencing with a recently implemented SaaS application. The company had contracted with a software vendor to implement their cloud based solution in support of one of the company’s core services. Since the implementation two years prior, the application had not been aging well. Feature updates were slow to roll out and more recently it had been averaging in excess of 24 hrs per day to handle the average daily load. The software vendor had not been able to resolve the issue to date. According to the financial services company’s CIO, the vendor was throwing extra hardware capacity at it but the situation couldn’t go on much longer without jeopardizing client services and blowing the targeted savings. So the CEO asked, “What would you recommend?”
The sales person quickly reviewed his company’s many capabilities and indicated the CEO’s problem application was a perfect fit for his company’s talents. He suggested a quick trial of his company’s abilities to let the CEO and his top technical managers judge their performance first hand. If that worked to their satisfaction, the CEO could extend a contract to resolve the performance problem with greater confidence.
On the Monday following the wedding, the CIO called the sales person and indicated he had an assignment for their company. The CEO had called the CIO on Sunday evening and explained the discussion with the sales person and his recommendation for a trial contract. The CIO had his folks check out the technology consulting company and found a stellar reputation and track record. He then charged them with finding an assignment that would be a suitable test. They found just the assignment – an internally developed internal marketing web site whose pages were taking abnormally long to load, a problem his staff had not been able to solve.
The sales person reviewed the opportunity with his company’s executives, they blessed the initiative, a one page contract was drafted and the sales person emailed it to the CIO for his signature the same day. The following day, the signed contract was returned and the project began.
To ensure all pages on the targeted web site loaded in less than 2 seconds and produced identical results to the existing implementation. The work would be completed in two months.
Bill Moher met with the company’s CIO the following day to thank him for the opportunity, to review the key players on the team and the approach they would be taking. He asked the CIO to assign his most knowledgeable resource to the project to help accelerate the resolution of the problem.
The plan of attack included a six step approach to solving the problem with as much parallel work as possible to accelerate the solution:
- Review the original goals for the website and work with the client to address any expectation gaps to ensure that all subsequent work reinforced that mandate – 2 days
- Review the technology infrastructure at the company and the architecture for the website – 4 days
- Based on the first two steps and independent of the existing design, draft a high level design leveraging the consulting company’s top talent – 5 days
- In parallel, review the existing design and performance issues – 5 days
- Based on that input, create a new or revised design for the application, develop and test one hierarchy to confirm that it addressed the issues and refine if necessary – 10 days
- Apply the proven new design to all remaining hierarchies and test to confirm compliance – 20 days
Once all components of the website were revised according to the new design, the solution would be implemented and monitored to ensure satisfactory resolution.
On the Wednesday, with the CIO’s assigned resource on board and Bill and his team of two in place, the work commenced. Bill’s team included himself and his two consultants with skills in software development, data base technology, software architecture and test automation to prove the revised solution delivered the same results as the existing functionality. Bill recognized that his success was directly dependent on the attitudes and capabilities of his team members. He always chose carefully. He would add additional resource as the solution became clear and the need arose.
The first two steps were completed in two days thanks to the knowledge of the CIO’s assigned resource and the expertise of Bill’s staff. The next three steps were concluded in four days versus the planned fifteen and focused on revamping the data base structure being used in the existing application. The rest of the application was reworked, tested and implemented in a little over two weeks. The total project took just over three weeks versus a planned two months. Web site performance was sub second versus the targeted 2 second response time.
Bill and his team updated the CIO in a ten minute daily update so the final result wasn’t a surprise. But the CIO was ecstatic nonetheless. In addition, the CIO’s assigned resource couldn’t stop raving about what a great experience it was working with Bill and his team. They were absolutely focused. They knew their stuff. There was an ongoing, frank and collaborative exchange of information. They were incredibly productive. The CIO’s assigned resource suggested to the CIO that there would be significant benefit for the company to do more work with Bill’s company.
And so the CIO approached Bill about taking on the SaaS problem the CEO had previously mentioned at the wedding reception. Of course Bill was thrilled to oblige. In three weeks, using a similar approach, Bill’s team was able to reduce the average daily load to three hours. But the most significant outcome from that engagement was the insight they gained about the company’s core application. Bill’s team concluded that the SaaS application posed a huge challenge from a security standpoint and would never deliver the benefits the company was expecting to realize. That resulted in a proposal to redevelop the application and bring it in house to take advantage of significant amounts of unused capacity. That proposal was endorsed by the CIO and approved by the CEO.
From an initial two month contract through a subsequent three week engagement, both very successful, Bill’s company earned the admiration and trust of the financial services organization’s executives. That resulted in a one year contract to bring the core service application in house. That engagement, using a similar approach to the other two contracts, delivered almost three million lines of new and revised code, involved up to forty people at the peak and was able to deliver the solution at about $1 per line of code.
Because the hardware and software architecture for the system was done properly, the third party firm hired to load test Bill’s teams solution was unable to slow the system with loads in excess of 300% of the maximum load the previous system had ever received.
Additionally, the CIO had secretly contracted with an industry leading security audit firm who was offered a bounty for any issues identified. The findings: zero vulnerabilities!
How Great Leaders Succeeded
Ralph Waldo Emerson said “Life is a journey, not a destination.” That is certainly an accurate assessment of this company’s relationship with its client. As well, it’s probably an accurate reflection of successful individual growth, both personal and professional. That outlook helped Bill, his team and his company achieve remarkable results and provided the foundation for delivering a number of best practices, including the following:
- Always explore opportunities – This contract wouldn’t have happened if the sales guy hadn’t shown an interest in the CEO at the wedding. The sales person didn’t know the individual he was talking to was a CEO but he took an interest anyway. When he recognized a potential opportunity, he presented his firm’s offerings. The rest is history. So, regardless of the situation or circumstances, show an interest in the people you meet.
- Prove yourself – The contact at the wedding resulted in a short term assignment. That successful engagement resulted in another contract. Knocking that assignment out of the park provided the opportunity to learn the environment and pitch a remedial solution. The accumulated credibility helped close the deal. The saying “you’re only as good as your last project” is a telling reminder that success leads to opportunity.
- Provide your own SLA – This company ran into difficulties on its core systems because it didn’t stipulate its target expectations and hold the contractor accountable for managing to them. There was no service level agreement. Quality factors, often referred to as non-functional requirements, are the scourge of too many failed projects. Knowing a client’s expectations about things like performance, security, recoverability, continuity, ease of use and scalability, for example, and managing to those targets improves a project’s chances of success immensely. Bill discovered that his client couldn’t readily articulate their expectations. He facilitated that discovery exercise to ensure he and his team knew explicitly what they had to deliver. In the process, he earned the client’s trust and confidence in his professionalism and leadership.
- Learn – Bill didn’t know much about his client’s business so he read some books on the industry. He also took a couple of online courses. He didn’t know a lot about the technology that was being used in the SaaS application, so he read some books – including manuals and whitepapers from the customer’s chosen technology vendor. He took a couple of online courses. Bill’s personal motto was and is “know as much as you can know”. That knowledge allowed him to converse intelligently with the company’s staff, from the CEO on down. It helped earn their respect. It provided a broader and informed frame of reference in his outlook. It made him look like an expert in his client’s eyes. It grew his expertise to help solve the problem.
- Build domain knowledge – This point is similar to the Learn point above but it’s worth differentiating too. Bill is a technology guy. He could have focused just on learning about the different technologies involved. But he learned about the business too. That broad yet focused domain knowledge gave him the insight he needed to provide the solution his client needed and the credibility to get the contract.
- Reuse – This is where technology architecture comes in. It’s equivalent to previsualization in the sports arena. Bill’s emphasis on thinking about possible solutions – business as well as technology, and exploring, at a high level , how elements of a solution could emerge, evolve and integrate was critical to his success. That world view provided a well- defined foundation and a framework for reuse – of concepts, designs, hardware and software – that allowed his teams to deliver more appropriate, higher quality solutions faster and at less cost.
- Build your best team – Bill attributed much of his success to an emphasis on acquiring the right staff, including a balanced mixture of education, experience, attitude and something he calls grit – a blend of courage, tenacity, resilience and a willingness to think differently with a touch of mischief for good measure. His secret sauce was creating project teams that would leverage terrific talent to achieve individual and team growth while delivering out-of-this-world project accomplishments.
- Shape culture – Building a great team is difficult. If there’s a corporate culture in place that thwarts that effort, outstanding results can be difficult to achieve. As was almost always the case, Bill and his teams operated within an existing client culture, with staff shaped and guided by that culture. Sometimes its effects were benign. Sometimes they were toxic. Occasionally they were empowering.
According to an article in Harvard Business Review, Proof That Positive Work Cultures Are More Productive Emma Seppälä and Kim Cameron, “Too many companies bet on having a cut-throat, high-pressure, take-no-prisoners culture to drive their financial success. But a large and growing body of research on positive organizational psychology demonstrates that not only is a cut-throat environment harmful to productivity over time, but that a positive environment will lead to dramatic benefits for employers, employees, and the bottom line.”
Much of Bill’s focus was on bridging the divides between his staff and his client’s staff and forging a new normal. It turns out, he was a bell weather of sorts. According to Gallup, the polling and analytics company, as reported in the State of the American Manager: Analytics and Advice for Leaders report, “managers account for at least 70% of the variance in employee engagement scores across business units”.
It is clear; luck has little to do with project success. In this case, Bill, his teams and his company were the authors of their own luck.
So do yourself and your colleagues a favour. Put these points on your to-do list for your career and future projects. And also remember; use Project Pre-Check’s three building blocks covering the key stakeholder group, the decision management process and the Decision Framework right up front so you don’t overlook these key success factors.