Whether Agile, Waterfall, Wagile or something else, we need to turn a concept or thought into a deliverable. We may do this in large waterfall defined steps (requirements first then design, then development …. , or in multiple iterations, regardless, we like to have a defined set of steps or phases that we all utilise to describe the evolution of outcomes and deliverables from that initial concept.
Just like breaking a large project into sub-projects, work-packages, activities and tasks, thinking about the phases the activities take to transform the concept into a deliverable is useful in estimation. planning, resource allocation, planning and delivery management.
You likely have your own steps or stages and your own naming conventions but we current use the following "5D” steps to successful delivery : “Define”, “Design”, “Develop”, “Validate” and“Deploy”.
Define ... Covers the areas of "ideation" - the birth of the concept or definition of the project
Whether we are building or purchasing the solution (as software or SaaS), it is vital that we clearly define what it is that we are looking for and clearly define the functional and non-functional requirements. These requirements need to be granular and traceable if we expect to be able to manage the project properly from an engineering and management perspective.
Breaking our requirements out into granular and manageable "pieces" (components, function points, features etc.) will add greatly to our ability later on to prioritise, measure and monitor progress and control the programme as it moves through its lifecycle. It also helps us to consider what we may have omitted (deliberately out of scope or not).
Design ... This stage involves getting into the next level of detail on requirements and preparation of solution options from a functional and a technical perspective.
There will be a functional and a technical design required which needs to cover functional and non-functional. Generally we find that teams focus solely on functional (primarily to exclusion of non-functional) and seems to stem from the fact that many project managers and delivery leaders may not have an in depth engineering or technical background. This is compounded by the fact that business users and stakeholders don’t really want to engage on non-functional so the time may not be allotted to carry this work out to the level required.
Develop ... This is the stage where the software (or technical components) are built and unit tested.
In general, developers are good at estimating how long it will take to deliver the functionality. Agile delivery tends to involve developers far more in the estimation and planning process as it is an "engineering focussed" methodology and this adds greatly to the accuracy of estimation and therefore potential to plan and deliver to more reliable timelines. To deliver better estimated in non-agile projects, models help as it encourages more engineering input to project management estimates early on in the project. We generally see significant gaps when it comes to estimation for integration of different technical components. Developers think and plan clearly for their work but seem to plan less for the work required to get their components working with other supplier or developer deliverables.
valiDate ... There are a number of steps here, including system testing, integration testing, user acceptance testing and (what is referred to by many in the business as) Model Office testing. "Model Office" testing is where a near working (pre-production like) system is put through its paces by the business, which allows the business to test their business processes and complete process documentation. This is an areas that regularly underestimates the effort of all parties involved.
System testing is where the developers test their code in an integrated environment with the rest of the system deliverables. Generally it would appear this is well estimated where the deliverables are built and tested by a single team. But the estimates are generally less reliable where the deliverables are from different teams or different parties
An area that generally get underestimated is in the area of developer and business subject matter expert support to the testing effort. Many times we see estimates that only allow a percentage of time for "testers carrying out testing" but did not take account of support from developers and designers in terms of analysis or fixing errors and access to specific SMEs to determine what the corrective action should be. Another areas of underestimation is the time required for the creation and maintenance of test data and environments. Areas that also get missed when planning include Code Consolidation (if the version being worked on for the project is a branch and as such, testing is on the branch, there may need to be an allowance to test again (regression) on the "merged with core" version), Production Testing ( generally test and production environment differ so some regression may be required in production, particularly non-functional tests),
Deploy ... This is the eventual "productionisation" of the solution. Referred to as deployment or "Copy Live".
Comments