It can be difficult to know where to start a new software project. Although it is an exciting time proposing innovative new solutions, engaging with suppliers and building cool new software, there is a lot of up-front work which is needed to get the project off the ground.
Due to their complexity, software projects pose a lot of unique challenges not present in conventional projects. This is because there are often a lot of people involved from throughout the SDLC (Software Development Life Cycle) as well as upstream/downstream systems, hosting environments and often, a broad range of stakeholders at various levels; not to mention the inherent complexity of building software.
Project Charter
One easy and straightforward way of capturing the early details for your project is to use a templated approach. There are many ways to do this, including:
- Project Charter
- Project Initiation Document
- BOSCARD
- Agile Inception Deck
I will run through the ‘Project Charter’ approach, but regardless of the approach chosen, there are certain things that need to be established in order to initiate your project such as:
- Problem Statement
- Business Case
- Goal statement
- Timeline
- Scope
- Team
Let's dig in to some of these topics in more detail in order to understand what details are needed and how they help to further the progress of the project.
Problem Statement
'First, start with why' as the management book of the same title states. All too often organisations can get ahead of themselves by leaping to solutions before fully understanding the problem. Any good project needs a 'raison d'etre' or 'reason for being' and by clearly documenting this you can help understand the value the project is bringing to the organisation, but also motivate and inform stakeholders so that they become active supporters of the project.
Business Case
Before starting any project, it's important to understand the business case in order to ensure that the solution will provide the required benefits to the organisation. Some organisations, typically larger companies, may require a minimum ROI (Return On Investment) with a payback of 3 years before they will even allow a project to progress. Business cases tend to be built around a number of metrics as follows:
- Cost reduction (Actively reducing ongoing costs, for example 'this project will allow us to remove a legacy system costing $8,500 per annum').
- Cost avoidance (For example 'We will avoid new regulatory fines of $10,000 per annum').
- Growth ('We will increase our sales value, thereby making an extra $20,000 per annum').
- Improve Net Promoter Score, retain more customers.
- Soft metrics, improve processes, reduce errors.
- Others.
Once you have all of the proposed improvements, both hard (quantitative) and soft (qualitative), these are all collated together into a business case document, along with the high level predicted costs of the project, so that people can be aligned on the benefits of the project and agree that it is worthwhile initiating. This should be a collaborative process, allowing for everyone across the organisation to input into it, as costs and improvements can come from a broad selection of places.
The transparency and alignment that writing and sharing a business case document brings is important because it allows people to:
- Identify and add any missed business case benefits / costs.
- Challenge any incorrect assumptions that have been made.
- See at a glance the benefits that the project is providing and therefore it's justification to proceed.
- Determine if there are any other similar linked initiatives where there might be an overlap.
Whilst writing the business case it is also important to start formulating your stakeholder map. To do this you break stakeholders into 4 separate boxes of:
- High influence, high interest (Manage closely)
- High influence, low interest (Keep informed)
- Low influence, low interest (Keep into account)
- Low influence, high interest (Anticipate and meet their needs)
In I.T. projects, you often end up with a lot more stakeholders than in traditional projects, due to usually requiring procurement, build teams, run teams, security, architecture, users, senior stakeholders, etc. Once you have the stakeholder map you can use this to start formulating your communications plan, to ensure that stakeholders are kept informed in the correct method and cadence.
Goal Statement
It's important to define up front what the success criteria of the project are, otherwise how will you know when the project is complete and delivering the desired benefits? These could be specific metrics such as 'Cost to produce widgets has reduced from $10 to $9' or they could be more general metrics such as '7 processes have been automated by the new solution'.
Some of these things will be present in the business case, but some might be less KPI related such as "Ensure the decommissioning of the legacy system'.
A common problem with measuring benefits is that there is often no good reporting and/or MI/Management Information data available to be able to measure before and after, so a good starting point would be ensuring that these things exist. If there is a BI/reporting team in the organisation this might be a good place to ask them to build the relevant reports, or if there is a reporting element to the new system, now would be a good time to start defining relevant reports so that you can measure the success of the project.
Assessment
Before starting to build a new solution, it's important to check that there's nothing available internally that fulfills the same requirements. Have you ever worked at an organisation which had 7 different CRMs all to achieve very similar things? If so, it's likely someone, somewhere forgot to do an architectural assessment.
It's tempting to find a solution to a business problem and then plough forward at full steam with implementing it, but this might not be right for the organisation who has to pay licence costs, support overheads, supplier management fees etc. That's why it is important to either engage the architecture team within the organisation, or if no such function exists, to complete this task yourself. Architecture teams often maintain technology roadmaps for various areas of the organisation, so you will be able to see the solutions that have been implemented and also those due to be implemented soon.
Once you've ensured you aren't building a solution that already exists within the organisation, it's important to find out what other systems you might have to engage with as part of the project. If integrations or APIs are required to other systems, it's important to document these early on as they can often represent a significant portion of effort both in terms of development and quality assurance. Additionally, such integrations introduce dependencies on teams outside of the project, adding complexity in terms of resource availability, change windows and stakeholder management.
Scope
At an early stage in the project it is important to get alignment on the scope of the deliverables for the project. Projects are defined pieces of work with a beginning and an end and there can sometimes be the temptation to keep them running longer than they should have been, perpetually delivering more functionality as it becomes apparent. Whilst continuous improvement, delivery and integration can be beneficial processes in the lifecycle of a product, it's important to identify this and move it to the maintenance phase of the products lifecycle.
Whilst documenting what's in scope for the project, it's also important to define what's not in scope. This is to prevent the focus of the project team being spent on things which they needn't concern themselves with but also to manage the expectations of stakeholders up front. If stakeholders are under the impression that something is going to be delivered by a project and then subsequently find out it is out of scope, they may try and pressurise the project team into delivering it, at greater cost and effort. For this reason, it's better to clear up these misunderstandings as early as possible.
Team
It's important to understand the proposed team size for your project, so that you may understand your budget and ability to deliver the project by a set date. 'Right-sizing' of a project team is very important. Too few people and your team members will be overloaded; too many people and the exponential increase in lines of communication makes the team unwieldy. Looking for logical splits in the project can help, such as front-end/back-end/QA/platform engineer, or splitting by project feature with an integration team.
Team design, size and composition is often closely linked with the chosen delivery methodology. Waterfall delivery, with large Design/Build/Test/Run phases can often accommodate large team sizes (i.e. 20 developers+), but this can later cause issues with merge conflicts, packaging and deployment issues at the big handover phases. Agile continuous delivery teams tend to be of a smaller size, with the ideal said to be between 5 and 9, but scaling to multiple squads can also present issues and needs to be considered, it's just you deal with it earlier in the life cycle of the project.
When sizing teams it is important to remember the old mantra from the popular book 'The Mythical Man Month' which states:
"Men (people) and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them. This is true of reaping wheat or picking cotton; it is not even approximately true of systems programming." Frederick P. Brooks Jr., The Mythical Man-Month: Essays on Software Engineering
That is to say, adding more developers to a software project often doesn't result in the increase of delivery that you might expect.
Timeline
Once you know what is being delivered at a high level (scope) and the team structure (heavily driven by the budget), you should be in a position to articulate a rough timeline for the project, whilst bearing in mind the classic project management triangle:
That is to say, if time is fixed and scope increases, then cost must increase to allow for it. Likewise if cost is fixed and scope increases, then the amount of time must increase to allow for delivery of the extra features. It's important that stakeholders are aware of this triangle early on in the project, or there can be a temptation to perpetually ask for new functionality, whilst expecting it to be delivered for the same cost and to the same deadline.
Transition to Service
At the point where the developed code becomes released to a live environment, ready for users to interact with, there are a lot of considerations which should be borne in mind throughout the project.
- Who signs off the code as being fit for deployment?
- Do we need to penetration test the system?
- What training and handover activities are required?
- Which team will be supporting it when an incident is raised on day 1?
- What support will the project team be providing and for how long?
Such questions can often be an oversight, left to the last minute due to taking a backseat to project build work, but they should be given consideration early on or they can lead to an unstable launch which undermines all the hard work done by the project team.
Conclusion
- Utilise a project charter or similar document to get all the stakeholders on the same page.
- It's better to over-communicate than under communicate.
- Ensure that the solution you are delivering has an appropriate problem statement to solve and delivers business benefit.
- Spend time creating the right team sizes and development approach which is tailored to the solution and the organisation.