1. Make Decisions based on Business Priorities, not Technology Features or Preferences
Regularly, we see decisions being made on technology features and preferences that are not aligned with business and stakeholder priorities. Stakeholders can get caught up on insisting their own business and technology features are represented and often lose sight that the business requirements take the highest priority. It is also important stakeholders and developers agree what the top software technology features and preferences need to be. For example, spending vast amounts of money automating the installation of a legacy solution when the system is not part of the business roadmap. Or choosing patterns that promotes business performance at the expense of reliability, when the business priority was to have improved reliability rather than higher performance.
It is therefore important that Project Managers regularly check on the number of features to ensure that the budget and delivery of the project isn’t compromised and to remind stakeholders what the end goal is. That being said, the technology features must support the business priorities to ensure that the software is of value to the business.
2. Agree and Document Final Requirements as a Group
Last minute changes to requirements usually disrupt and delay the various stages of software development.
For bigger legacy monolith projects: A well monitored and collaborated agreement on business requirements will help to manage stakeholder’s expectations right from the start of the project. Stakeholders should be encouraged to debate and prioritise requirements as a group. Any decision changes that impacts the various stages of software development must be documented and communicated back to the stakeholders for approval. This approach will reduce any last-minute changes or surprises, that can cause costly delays to the project.
For agile environments: If the project is more of an agile mindset, there needs to be a balance, acknowledged by all involved parties, between the depth of requirements specified up front and the flexibility of feedback & changes that can be made after regular showcases. The difficulty here is to find the right balance that works in order to get the end state that most accurately fits the business wishes (conscious & subconscious) but at the same time gives good timeous direction for feature teams to work towards. Showcasing mock-ups early on prior to serious development starting, helps with this process. Identifying non-negotiable s vs flexible requirements up front also helps.
3. Document all Decision Logs for each Feature
Team members and developers often join the project team during the project and do not have the history or understanding of what the initial business priorities and requirements are. This can cause duplication of work and cause delays for the development of the software.
Maintaining a decision log will provide a clear view of the process and phases that the software had gone through from inception to final delivery. A decision log complements the business and technical requirements, providing context, choices and known limitations, and may cover any grey areas in the requirements. For example, if a support team member is assigned during the maintenance phase of the project, the decision log allows that team member to better understand the business priorities and requirements and make appropriate technical decisions if an incident arises.
Team collaboration tools, such as Confluence, are useful and can assist developers and support teams by providing decision logging facilities. The decision logs have all the information documented like the Aim, Status, Key stakeholders involved, Background on the subject, Important notes and Comments. An example of a decision log is shown below.
Name of Service:
| Status | IN PROGRESS |
| Stakeholders involved | John Doe, Pat K, Sam Green |
| Date | 31-Apr-2017 |
| Created By/Owner | Jane Austin |
Background:
The service should reflect the business context as well as the functionality.
Comments:
John Doe: How about ‘reservation-options’? @Pat & @Sam what do you guys think?
Pat: I think this is good. Let’s see what Sam thinks about this. I have attached a reference guide as well.
4. Behaviour Driven Development
In most organisations, business stakeholders and end users have little software development knowledge, and find it difficult to articulate concrete examples of the behaviour they expect to see from the application. The application then does not realise its full potential because the coding and acceptance criteria do not reflect the desired behaviours and expectations of the business.
Behaviour Driven Development (BDD) is an agile development methodology that encourages collaboration between developers, project managers, testers and the stakeholders. The methodology includes describing the business requirements in plain language so stakeholders can understand how their requirements are represented in the software. This allows the stakeholders to clearly see that their requirements have been achieved.
The requirements of a feature are described as scenarios in Gherkin language with ‘Given, When & Then’ statements. An example is shown below.
Given When & Then Example:
| Given a customer has 1700 credits points and 300 purchase points |
| When the customer makes a purchase of 100 dollars |
| Then 20 purchase points should be added to the customer’s account |
| And 300 credit points should be added to the customer’s account |
The common understanding of requirements is reached through discussions between business analysts and software developers. These discussions help the developers to clearly understand the business and give Business Analysts a clearer perspective of the developers’ approach.
In conclusion, it is important that all team members of a project employ tools, methodologies, processes and cultures to enable collaboration between stakeholders, developers and project members in different areas of the business. A team that is aligned to a common goal is the most important factor when defining a software’s success.
