Arguments For A Project Kickoff Strategy

How to properly initiate a software project so that it has good chances for success.

You may not be a project manager. Perhaps you are a developer who likes to code and solve technical challenges. The organizational matter is something you care less about. After all, your company is likely relying on some agile methods and there are product owners and/or SCRUM masters to handle the process. You just need to build new features.

While that’s true you have to sometimes get out of your comfort zone. A few arguments why:

1. Many Organizations are Agile on Paper #

If a company is relying more on the right-side items it is not correctly practicing agile.

Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan.

Manifesto for Agile Software Development

Adopting agile is generally difficult. It doesn’t come naturally which leads to impediments and internal refusal. Applying principles, holding meetings/events, or hiring SCRUM masters is barely enough, though it is where some companies will turn their focus. The result is running a process that looks agile-driven but without the spirit. People tend to nourish in environments with different setups—those that fuel motivation and proactivity. If you are a developer in a non or semi-agile organization you can do a lot to improve the working process.

2️. Management with Non-technical Background #

Engineering managers (EM) do a great job of coordinating people and keep track of the project progress. They remove blockers and help you stay delivery-focused. It’s a bonus if they also have some technical experience. In that case, management is more likely to empower people familiar with the product internals and the process itself (programmers, QA). Contrary, leaders represent the business and are quite often detached from the production line. You as a developer are not. In addition, depending on your career ladder coordinating efforts across the team rather than working in a silo should already be part of your job description.

3️. No One is a Single Source of Truth #

Someone needs to collect all pieces of the puzzle. A hero who knows where and what to look for. The “where” is often located in the “dev department”. For that reason it comes very naturally for a programmer to sync people of the same kind. This is especially true in flat-structure organizations popular in Europe fx. Note that no tool is going to magically do the job where face-to-face collaboration is required.

4️. Prepare for Hidden Information #

Failing IT projects have something in common—they mishandle hidden information which in turn causes frequent changes late in the process and delays. The hidden information is buried in the system and is not always visible upfront. It tends to suddenly pop in during development (sprints, iterations). The later it happens, the worse. It is very likely for the engineers to be the first to discover hidden user stories. In SCRUM fx. a good opportunity to inspect for hidden information is the Sprint Review.

The above said probably sound familiar to you and your team. But there is good news: it is possible to minimize the damage if you focus on a few specific problematic areas.

The Problem #

Generally, a developer doesn’t have the power to solve all organizational problems and often shouldn’t try to. But he/she can manage hidden information and sync teams because these activities tend to endanger everyone. The project will be a pain. People will burn out. “I don’t want to work with this person again”. Finger pointing…

You shouldn’t aim to manage the whole project but you can ensure a clear start.

Why? Because…

They Will Blame You #

Management may do so because you are the one whose work is visible. It doesn’t matter if the requirements were not clear. The delivered product is buggy and lacks particular features stakeholders were interested in. Your project got delayed.

What Can You Do #

You can do some preparation work and stick to a simple execution guide. It will help you identify hidden information early and during the project journey while adding some structure to the process if it lacks such.

Part 2 of the series will go over that in more detail with several practical actions you (the developer) can take.