Getting Involved Early

A while back I read a great article that outlines both the challenges and advantages of getting all necessary parties involved in a project early, including developers and other “tech” people. The content resonated with me, since my team was in the midst of this exact situation — we had started to participate in the “initiation” phase of projects. I am a software engineer and most of my team are also software engineers, my viewpoint here is getting people like us involved early.

When we say “initiation” of a project we are talking about discovery of risks, project goals, ROI, scope, etc; initiation is not strict requirements gathering. As we move into executing on the project we follow our agile mindset to build an initial backlog and continually adjust as we learn about our users’ needs. Getting involved early will allow the team to effectively navigate a project in a number of ways–in particular it helps develop measurable outcomes, reduces waste and provides continuity for the team.

Measurable Outcomes

A central goal in the initiation is the identification of project outcomes and how to measure them. This has proven to be a VERY difficult task. In the first attempt at gathering this information we usually end up with “fluffy” outcomes and measures–things that are more “feel” than something quantitative. The first version of these outcomes have typically been put together when the concept of the project is being developed. Since it is just a concept at this point it stands to reason that the outcomes would be a little “fluffy”, but as we start to turn that concept into reality, that is when getting a team involved early is important.

Folks close to the problem often have a “feel” for the outcome; others that are not as close can bring a different perspective. If we have solid, measurable outcomes, we can be much more confident in the effectiveness of our work. If team members that may not be close to the problem are involved early, for example the software engineers that will be building the solution, they can help drive outcomes that can be measured instead of just felt, and that’s what we are really after. These metrics are important and getting more people involved early allows for different viewpoints on the outcomes to be shared and discussed. It allows for the entire team to have a clear understanding of what we are striving to accomplish from the very beginning.

The desired outcomes of a project shape all of the work done on the project. Allowing the entire team to get involved early and have input on the outcomes creates accountability with everyone to make sure that choices made during the execution of the project are inline with the outcomes.

As developers and engineers we know all too well that things change (new risk, scope change, etc). If the entire team is fully aware of the outcomes, and something comes up that puts those outcomes in jeopardy, then anyone on the team is armed with the knowledge that will allow them to “pull the andon cord” and have the team stop and evaluate the situation.

Reduce Waste

We worked on a project recently where we were not involved early; the project was eventually successful, but it started out with a lot of waste. While there were technical folks involved during the initiation of the project, Their work was handed off to us, to develop a solution. When we came onto the project we spent a lot of time re-running spikes and trying to understand the decisions that were made; we lacked context and had to spend the first few weeks rebuilding that context.

Sometimes getting involved early in a project results in less work than expected. Our team worked on another project recently where gathered all of the necessary initiation items, senior leadership reviewed the outcomes that were identified and realized that there were more important efforts that needed to be worked before the one at hand. This was great for us, because of our due diligence we didn’t spend time on work that was relatively unimportant to the business!

In another case we were brought in early, and as we worked through the initiation, it became very apparent that the project didn’t require much engineering effort at all. Due to the fact we had all of the context we were able to make a quick and informed decision to step away from the project. A key takeaway from this last example is that you should always be willing to speak up if something doesn’t feel right. Had we not done that, we may have stuck around on this project just because we were assigned to it; instead we raised our hands and made ourselves available for other work where we could provide more value.

Continuity

When we get involved early, the things we learn are invaluable; the rapport and vernacular that is shared from the very beginning lives throughout the project and makes having hard discussions and making hard decisions much easier. In the early stages of a project we get to know how everyone works, how to adjust, and how to be a team. Context is a very powerful thing; the context you gain by getting involved early will be long lived and understood by everyone from the beginning to the end of the project (and hopefully beyond).

As developers and engineers, by nature we tend to want to dive in and start solving the problem; all of this “discovery” — with its discussions and meetings — can be boring, and trying to get everyone together to make the right decisions can be frustrating. Don’t let this scare you, and don’t be afraid to get involved early — I don’t think you will regret it.