Project Inefficiencies – or how to improve the project execution through functional specifications
To continue my article series on project inefficiencies and project management challenges, I need to mention functional specifications (also, functional spec, specs, functional specifications document (FSD), functional requirements specification, functional designs).
When you work in the field of systems engineering and software development, functional specifications are simply documents which specify the functions that a system or a component must perform. Functional specifications are then the base for the implementation, they should be ensuring that all user expectations are met.
Over 20 years ago, when I started to work on IT development projects as a programmer, the importance of creating functional specifications were intensively discussed – including the approval and sign-off by the business before the start of the implementation. Nowadays, as everybody wants to be agile, it seems that functional specifications are no longer required. Implementations jump straight from a requirement to the task which needs to be implemented.
Personally, I still believe that this is the wrong conclusion and an illusion to believe that time and effort can be saved by not going through a proper functional specification and therefore design phase. In agile, the functional specifications might be called differently, for example user stories, but they are still required.
I would like to share the challenges most project managers experience when working on a large scale, international IT projects with company internal IT departments:
- In many projects, functional specifications are created based on high-level requirements which are first translated into tasks and then implemented. There is still plenty of room for interpretation of the requirements and as a result, the final product does not match the requirements, resulting in rework.
- It is common best practice to have functional test cases written parallel with the creation of functional specifications. But when there are no function specifications, no one can write test cases, so their creation gets pushed back, leaving the question of how they should be created – if not in parallel and not based on functional specifications – wide open.
- As a consequence, test cases are finally created by the implementer who translates the requirements into development, resulting in a functional test being prepared by the same person doing the implementation. This process clearly has a high risk of faulty interpretation.
- Overall, in many large IT development projects, there are no audit trails and no trace records showing which requirements are implemented, designed, developed, and tested throughout the development cycle.
- When, as a project manager, I have no way of knowing who did what and why, then the process has a very high failure risk.
What can a project manager do to handle these challenges?
- Independent of the implementation methodology (agile, waterfall or mixture of both) functional specifications need to be done – regardless if you call them epics and user stories or use cases and model specifications or just functional and technical designs. It is of crucial importance that the requirements are translated into something the business can understand. They can then verify that this is indeed what they are requesting. Business should sign-off the specifications and only after their confirmation, tasks can be created and implementation begins.
- Especially when working with the agile methodology, the project manager needs to make sure that “agile” isn’t used as an excuse to skip crucial steps in the development cycle to save time. After all, “agile” just means that the development is a constant process with very short cycles to allow later adjustments of requirements. Agile does not mean you can skip necessary development steps (analysis, design, build, test, roll-out) – the steps might be called differently in different methodologies, but they are still all necessary.
I strongly believe in processes. Projects are efficient, when the overall process on how to translate the expected project goal into requirements, designs, implementation, test cases and then a successful cut-over is efficient – and if no step is omitted.
