Company: Public Consulting Group
Project: NC based development initatives
Background
Organic growth… If I were looking to build a buzzword bingo board for business catch phrases, this would be as guaranteed as the free center square. But if you are not careful, applying this concept to system design and support can start to look very similar to simply justifying a lack of rigor.
The problem with unstructured organic growth is that it emphasizes meeting an immediate need over long-term sustanability. For technical implementations, this can create the problem where each new engagement costs increasingly more to implement and sustain, and yes you will eventually exceed what the market can bear.
However, there are substantial benefits to lean development, creating a minimally viable product, and not over-engineering solutions whose relevency is not certain. So how do you strike the balance between organic growth and the efficiency of structure?
I noticed that our NC projects needed an answer.
Scope:
The focus of this effort centered around NC development initatives. At the time and adjusting for scale, our NC projects had the highest bug rate in the nation for our platform. Our team was run ragged with emergency fixes, inefficient testing processes, delays, and costly updates. The reason was two fold:
- Our clients pursued the greatest number of integrated services and custom add-ons, leading to the most complex implementations in the country
- NC school districts are data and tech contious, with systems centered around the research triangle park (RTP) often leading the way
Our innovation and flexibility are the reason why, for instance, we grew to support over half the EC student population in a state where a free solution was available; and so pulling back on client driven growth was not an option.
Additionally, there were major structural constraints I could not control. External project updates and core functions all ran the risk of impacting our client systems.
Still, I could impact NC based development, and there had to be a better way.
Approach
My method was not ground breaking: I started talking with people. Client reps, developers, delivery managers, senior leadership, and clients. What I found was that even though we all had the same goal of a stable and flexible platform that served teachers’ needs, there was a misalignment on priorities. Everyone was concerned with on-time delivery, but from there:
The ‘ah-ha’ moment in this was my realization that our unstructured, organic growth approach to meeting client needs applied downward pressure on innovation as project scale increased. Our teams could be more innovative if we defined a clear set of tools and standards to work from.
You can build a better house faster if you don’t also have to construct each tool you use.
Armed with this information, I drove a series of standards adopted and further honed by our NC team. To manage the work, I:
- Lead the creation, revision, and maintenance of system templates for all deliverable functions
- Organized and delivered multiple team alignment sessions to define how we were going to execute work moving forward
- Sunset redundant design and development methods, coordinating with our developers to determine what offered the most flexibility while retaining an organized code base
- Identified a ‘standard’ method of execution, and aligned any similar activity to that standard for all new development work
What we did not change was the priority misalignment. Each group was held accountable to different metrics, and we were not going to move that needle. What we did do is create a philosophy and approach to engagements, supported through approved templates and proceedures, and use these processes as a means to guide and manage priorities for new engagements:
The result of this effort was a dramatic reduction in bug tickets, bringing us in line with national averages even as our project complexities spiked due to multiple new service offerings and the introduction of a statewide system. Our state’s processes have since been adopted by national leadership teams and applied to external project updates and core functions – those areas I was not able to initially influence.
Want to talk about system design principles and building a team vision? I’d love to hear from you.
David Whitcher 