Insights

Success Through Learning From Failure

Success Through Learning From Failure
6.22.2018
Success Through Learning From Failure

By John O'Neill

Senior Client Partner

To know what good looks like, sometimes it’s instructive to know what bad looks like. I have firsthand experience with both from two different client engagements. One is a success story, one was a learning opportunity. In both examples, success or failure came down to three things that we often take for granted: expectations, communication and measurement. Get these three things right and you’ll usually succeed, but good luck if you botch even just one. In each section I’ll share some teachable moments followed by examples of applied lessons learned.

Expectations

Learning engagement: Before being humbled with this first client – a large healthcare company in the manufacturing space – my team was excited to create digital services that would support their products and begin their transformation as a software-led service-based company. It was not the vision or strategy that was the problem. Our problems started with incorrectly-set expectations. The first nail in the coffin was building robust plans with highly-detailed features. Our focus started on accomplishing the vision, but psychologically, the moment we specced out detailed features, our focus shifted to accomplishing those features – and our team lost focus on accomplishing the vision. In order to avoid a lost focus, our plans must be outcome-oriented, not feature-focused. Who cares what features we build if we accomplish the outcomes we envisioned?

Successful engagement: In this partnership, we were able to build and launch a game-changing product, completely new to the industry, within 12 months. It debuted at a global industry conference this spring. To do this, we guided leadership in aligning scope to business goals versus detailed features. Our goal was to launch a core product that met the key vision and business goals by the time of the conference. Not having the features mapped out in the scope was a big leap of faith for everyone, especially the client’s leadership and procurement — but this was the beginning of truly doing things differently. The stage was set at our project kick off led by our executive sponsor. Every member of the team — client stakeholders and my colleagues — was invited to hear the vision, goals and how important this product was. Our team discussed how we’d be working autonomously, and the importance of operating as a team. There would be no excuse about one component being behind; if something was behind, it was on all of us to figure out how to get it done.

Communication

Learning engagement: We all talk about the importance of cross-functional teams in building software; more important is cross-departmental teams with a collective focus on the vision. In this engagement, stakeholders from different departments within our client’s organization seemed to have competing agendas. There were too many empowered decision makers who were only looking at things through the lens of their own contribution to the project. Differing opinions led to constant shifts. Communication failure is the number one cause of scope changes and costly rework.

Competing priorities and lack of cross department alignment led to unproductive political battles and moral issues within teams. Leadership shifted from being motivational champions to investigators trying to figure out who was responsible for the overages and delays.

Successful engagement: One of the most overlooked keys to good communication within a team is building relationships. Getting all the database engineers to work with designers and strategists required a few team outings early in the engagement. Helping the client’s marketing team shift from asking for specific features was like teaching someone a new language. The time we spent together helped build empathy for the challenges of each others’ roles within our team. I knew something was going to be different when I watched our executive sponsor talk for over an hour to one of my automated test engineers about how important every individual is to the success of this project. Our executive sponsor attended every weekly status meeting and demo, regularly congratulated team members for individual contributions, and thanked them for their commitment to our work. The team gelled and we operated like a startup with no titles or egos. We were always reminded of the shared responsibility for success. We broke down geographical barriers by building relationships and respect for one another’s individual jobs. This improved communication led to very little rework for our autonomous team.

Measurement

Learning engagement: With features being the main component we were measured against, we collectively lost sight of the vision and other areas of measurement that are key to successful product development. Measuring feasibility, viability and usability took a back seat. In the end, the project failed due to unanticipated feasibility and viability issues at rollout.

Successful engagement: Success was purely outcome-based, allowing us to stay focused on accomplishing the vision. We also measured successes as a team, not individual groups. We put additional emphasis on measuring feasibility, viability and usability. Our business analysts and strategists met with customers to understand the feasibility of integration into their current workflows. We continually tested UI prototypes with customer domain experts and technicians in the field. We implemented robust tools, purposeful rules and a process that tracked the progress of full-system readiness, not only the progress of individual components. We also had extremely detailed defect-rate tracking, with all critical items under constant and precise monitoring. Our scrum master established true velocity from the start, providing easy predictability when changes or additional features were introduced. It was no longer a debate of what it would take to add another feature for the marketing or business stakeholder. For any change, we could show a clear picture of the true impact to velocity and potential risk to system readiness. My scrum master and architects set up systems to get realtime push notifications as stories were completed. This level of sophisticated, purposeful tracking and decision-making allowed us to launch the project on time.

Takeaways

Ultimately, what I learned from both engagements is the importance of working cross-departmentally, that politics and poor communication blow budgets and kill projects, and the need to shift toward a model of shared responsibility with shared expectations. It’s essential to implement purposeful rules of measurement. Set up robust tools for predictability and traceability, and always be measuring full-system readiness.

Most importantly, shift the mindset from features to outcomes. Technology today is moving as slow as it ever will; we need to leave room in our plans for change to keep pace with technology. Set the vision and the necessary parameters of your transformation and let your team figure out how to get you there. In the end, who cares what features end up in your product if you’re accomplishing your transformational goals and vision?

Published on 06.22.18