Learn from Failure – Dev to Founder – Brian Hattaway

Build//Better BuildBetter, Developer Career Development Leave a Comment

Joining us on the BuildBetter Blog today, is Brian Hattaway, Founder of Procore Resource Group. An experienced developer, Brian offers his unique insights on growing a business, and he has shared with us some of his tips. Enjoy!

No worries, no SPAM. Opt-out anytime.

Website: http://www.procoreresources.com/
LinkedIn: https://www.linkedin.com/in/brian-hattaway-7850761

Learn from Failure

Sometimes you learn more from failure than you do from success.

I started my career as a developer for Accenture, then gradually transitioned into larger roles as a Technical Architect. I loved the puzzle of assembling technology component Lego blocks into full business solutions. I had highly capable and intelligent developers that worked for me…until we met “that” client: The client who gave me 100 vaguely-worded statements, and insisted that those were the requirements to change their business.

We tried. We failed. I learned. If you can’t define your business processes, even the smartest technical team won’t make a project successful. I left my Big 4 consulting career and started ProCore Resource Group on a methodology designed to protect clients from their own shortcomings as process architects. Here’s what I learned as I started doing strategic consulting for clients who needed to define their requirements:

  1. Clients don’t know their own processes – even the experts don’t know. You need to interview the actual practitioners and front line workers to find out what’s really happening.
  2. Large design sessions aren’t productive. In reality, 30 people doing design is more like 3 people talking and 27 people doing email.
  3. Nobody plans for the “unhappy path.” Every process flow I’ve seen outlines the perfect process flow. However, 80% of the work always lies in putting a process back on track to the happy path.
  4. If someone hands you a list of their requirements, politely disregard them.

To be successful in managing a change program for your client, there are a few rules that I’ve learned to follow:

  1. Define the REAL business process.
  2. Define all the pathways where things go wrong, and define all of the process steps needed to recover to the happy path.
  3. Once the processes are defined, it will be easier to see how to assemble the technology components you have available to satisfy the steps in the process.
  4. Once this mapping is done, the requirements can then be defined. If requirements are developed prior to defining the REAL business process there will be holes, leading to missed requirements and missed expectations for the deployed systems.

Once your team has a solid understanding of the process flows and objectives of the function, they will be able to deploy the right solution to meet the needs of the business – with the right outcome the first time. The lesson learned the hard way was that when you skip process definition, a development team cannot make software that makes the users happy and the business viable.

We founded ProCore to ensure that as we built technology solutions for our clients, their business processes were faithfully represented before we designed the solution. This ensures our development is done correctly, and our designs meet the actual needs of the business versus the perceived needs of stakeholders on the sideline.


About Build//Better

BuildBetter eMagazine, brought to you by Stackify, is a free downloadable publication bringing together insight and advice from some of the smartest minds in the developer world. Each quarterly issue is packed with exclusive tips and tools from industry leaders, helping developers work better, code better, and build better careers.