Sharing is caring!

In this post, I want to discuss approaches in managing a software development project, specifically at the start of the project.

When advising clients on their technical strategy, and overseeing the implementation of this strategy, I will aim to put in place the right development team structure and project model based on the needs and resources available to my clients.

Sometimes though, I do not get to assist with the development team structure or project model. These are cases where the client has already engaged with a development agency.

This variety in agency choice provides a corresponding variety in terms of development approach used at the beginning of projects.

Some agencies will claim to be fully agile, yet have a very lengthy discovery phase where no development is performed, only analysis.

Other agencies will want to commence development immediately and perform all analysis just in time.

Others will choose to balance this, with an analysis phase overlapping development, with the actual development starting halfway through the analysis.

My point is that there are many different approaches, even though many would describe themselves as operating in the same way.

How much pre-development work is required?

Outside of the extremely rare case that a fixed detailed specification is required before any kind of development can commence, I would recommend that there is some form of upfront analysis work performed, before engaging a development team.

I think it’s important to have a clear business vision, but also a certain level of validation performed before any kind of development could deliver success.

There needs to be a base level of product and following technical analysis work to provide clear direction to any project. 

For example, I have worked with one client on a project that had a 3 month analysis phase at the beginning. 

There were various reasons for doing this, and I would not recommend it to quite this degree for most projects, however, the output of this process was extremely valuable. It provided:

  • A clear summary of all of the different types of users and stakeholders of the system
  • A concrete list of potential business opportunities for the client, including ones they had not initially identified themselves
  • A list of potential product features based on considering user workflows and business opportunities together
  • A list of non-functional requirements that would be essential to the project success and acceptance.

With the above information, this allowed the business to clearly market the product pre-launch, form detailed roadmaps for both internal and external communication, and begin a rapid development project with a detailed product and technical roadmap in place.

These product and technical roadmaps serve to massively reduce the risk of the project to the business, and whilst it might not fit everyone’s definition of an agile product, in practice, it allows a very high degree of agility because we all have the context and foundations in place to make rapid decisions.

Leave a Reply

Your e-mail address will not be published. Required fields are marked *