How optimal is your approach?
A system development project involves different disciplines, and will always have a level of uncertainty. This uncertainty implies a degree of change, complexity, and risk. The chosen project approach will affect the success of the project. Why and how should a project approach be selected? This article addresses agility and various approaches for system development projects.
Selection of project approach
The project approach is the way in which project deliverables will be realized . A project approach consists of a set of applied methods, techniques or tools applied to satisfy expectations and needs. Project characteristics such as the level of uncertainty, the available resources and the project success criteria should influence development of a successful approach in each system development project.
Initially, before a project approach is selected, the relevant stakeholders are identified and their expectations are discussed. Their need for information and involvement during the project are also discussed and analyzed. Measurable project objectives and related success criteria must be identified, discussed and prioritized. All this is documented together with other initial high-level information, such as project purpose, prioritized high-level requirements, and project exit criteria. A question that should be answered by the customer (or sponsor) is in regard to project constraint priorities: Is the quality, time, functionality or cost the first priority? All the initial communication described above is useful input to find the approach that best fit with all priorities.
The prioritized success criteria are used as the guiding principle for the approach to be developed. Factors that may impact success must be identified. Further, through the approach development, the necessary success factors are selected to satisfy the success criteria. The chosen approach should also be based on a life cycle model with characteristics that match the project characteristics. An example of project characteristics is considerable uncertainty that implies a high rate of change, complexity, and risk of rework. For this example, an appropriate approach can be based on a life cycle model that allows the project to tackle a high amount of uncertainty, via small increments of work.
Prior to any detailed planning, an initial approach for a project may, among other things, consist of:
- A project life cycle model (e.g. An iterative model)
- Rules with respect to decision-making
- The way of gathering information and reporting
- The different meeting structures
- The responsibilities and authorities
In order to increase project success, the project approach must be customized because it depends on the success criteria, the available resources and the complexity. The chance of success can be increased by involving the people set to carry out the project work in adapting the approach. There are many different causes of complexity, for example a short duration, a large number of people involved, an insufficient budget, uncertainty in estimates, or external dependencies such as other projects. The project approach can also be changed during a project. It always depends on the situation.
Characteristics of project life cycles
A project life cycle is all the phases/periods from idea to a final delivery. Characteristics of the following life cycle models will be addressed:
- Sequential (e.g. Waterfall)
Traditional Waterfall and V-model life cycles, with their sequential processes, have a lot of planning upfront. They also have a lot of analysis and design before the build phase. The waterfall life cycle model, shown in figure 1, is most appropriate when the requirement are well known and fixed, in projects with stable teams and low risk. There is a review at the end of each phase to verify the work and to decide if the next phase can start. Testing starts only after the finished build phase because the phases do not overlap. The waterfall model can be problematic if used for long and complex projects, and for projects with many changing requirements, due to the sequential processes without several iterations.
An agile life cycle can be an alternative to the waterfall life cycle. Project approaches based on an agile life cycle model are commonly used. Agile life cycles are both iterative and incremental. This means both repeated activities and frequent small deliveries, as shown in figure 4. The goal for agile approaches is to deliver a continuous flow of value to customers and achieve better business outcomes. Feedback on each delivery is used when planning the next iteration. Agile approaches will follow the principles of the Agile Manifesto .
Figure 2 shows an iterative life cycle. An iterative life cycle can be appropriate when the complexity is high and when frequent changes are expected.
Figure 3 shows an incremental life cycle. An incremental life cycle can be appropriate when the customer want frequent smaller deliveries with a subset of the complete solution because of business needs that cannot wait. Further, frequent reviews improves the quality. If an iteration-based agile approach is used, the team collaborates to finish the most important features in each iteration (each time-box).
Agile life cycles have several advantages for system development projects, but there are also some potential challenges to be aware of. Quantification of effort, time and cost is difficult at the beginning of an agile project life cycle because the team does not have all the upfront estimation and planning as in waterfall. However, the team can provide better estimates after a few iterations (sprints), when the team has established a reliable velocity (average amount of work completed in each iteration). Another challenge is risk for insufficient emphasis on necessary design and documentation. Further, a risk is also having only inexperienced engineers in an agile team – they should be combined with engineers or a project manager that has the experience needed to make the required decisions during the development process.
An example of a specific life cycle is use of a model that group increments and/or iterations into several large phases, where each of the phases are divided into several smaller time-boxes. This enables high-level planning of one larger phase at a time, and more detailed planning for each time-box.
A commonly used hybrid life cycle is a combination of waterfall and agile. For example by using some agile methods such as short iterations (e.g. 2 weeks), backlog, frequent demonstrations, and retrospectives, but still follow other aspects such as considerable upfront estimation, analysis, and progress tracking according to waterfall approaches.
Use of both Scrum (including a board to visualize the flow of work) and elements of the eXtreme Programming (XP) method is a common blend of standard agile methodologies . The Scrum framework provides guidance and description of concepts like product owner, scrum master, product backlog, sprint planning, daily scrum, sprint demonstration/review and sprint retrospective. Further, XP inspires engineering practices like continuous integration, refactoring, automated testing and test-driven development.
A pragmatic approach can be used together with waterfall, agile and hybrid approaches. A pragmatic approach will only use the practices that make sense for the individual team. The team will remove any unnecessary ritual, and focus on getting the quality and work done as quickly as possible. Agile is not what you do – agility is how you do it.
Attention to quality is a premise to release anything rapidly if an agile approach is used. Regression testing and testing at all levels are important – from unit testing to system and acceptance testing. This applies to both agile and sequential approaches. Several types of tests may be needed, for example stress, compatibility and usability testing, as well as load and performance testing. In addition, simulations are often useful for interim test of hardware and mechanical designs.
Figure 5 shows four life cycle categories and their characteristics related to degree of change and frequency of delivery. No life cycle is perfect for all projects. Instead, each project should find an optimal balance between the characteristics .
Approaches based on a waterfall life cycle takes advantage of things that are known and proven. Detailed requirements and plans are created at the beginning of the project. This means that the sequential waterfall life cycle can be suitable for a small project with fixed requirements and low risk.
Agile approaches have early and continuous delivery of valuable products or results, and the projects can adapt to high rates of change. This can increase the customer satisfaction. Just-in-time requirement analysis means that a project starts with high-level requirements, and that the requirement specification is developed into more details during the project. Agile project teams should look for early and frequent deliveries to obtain feedback. When teams deliver small increments, they will better understand the true requirements. Software development is normally about learning while delivering value. Hardware development and mechanical development are similar in the design parts of the project. Therefore, an agile mindset can also be relevant for parts of hardware and mechanical development processes.
Magne Jørgensen at Simula Research Laboratory has recently performed a survey for 122 recently completed Norwegian IT projects: “Requirement changes in IT projects: Threat or opportunity?” . The results indicated that it is useful to postpone adding details to the requirement specification if the project is large, has an agile approach, and/or has a time-and-materials contract. For non-agile approaches in IT projects of small or medium size and with a fixed price, a detailed requirement specification can be preferred and perhaps even necessary. The results also indicated that requirement changes during the projects due to learning contributed positively.
Requirement changes due to external changes, and imperfect early analysis, were negative for the successfulness of the projects. Half of the projects with a well-functioning agile process, time-and-materials contract, limited detailed requirements at project start-up, and frequent requirement changes during the project life cycle, were successful, and no projects in this group had a worse outcome than acceptable.
Teamwork success factors
Some examples of common teamwork success factors are clear objectives, joint responsibility (supporting one another), open and honest communication, mutual respect and trust between everyone, and flexibility (adapting to context and changes). Prioritizing, as well as rapid and transparent feedback, are common success factors for high-uncertainty projects that can imply high rates of change, complexity and risk.
A project needs several skills, and a team that has all the skills necessary to complete the work is a cross-functional team. The team members themselves should determine who will perform the work prioritized for the upcoming period. Empowered teams are more accountable and productive. Further, by limiting the work in progress, the cross-functional team members can collaborate more to deliver completed work. If team members are not 100 % allocated to a project, they can experience productivity loss because of task switching. Conversely, when every team member is 100 % allocated to a project, they can continuously collaborate and make the team more effective. The size of an agile team is also of importance. The PMI Agile Practice Guide  and the Scrum Guide  recommend a development team size between three and nine members.
Based on the project approach needs, a project manager may be desired. A project manager can add significant value in many situations, for example to facilitate a chartering process and collaboration, coach, give direction, help and advice. An effective project manager can also help meet objectives and expectations, help respond to risk in a timely manner, help resolve project issues, help optimize use of resources, help manage changes and constraints, and help deliver the right products at the right time and cost.
Measurement of performance and progress
Project measurement data is essential for improved forecasting, reporting and decision making. Two commonly used and recommended methods for empirical and value-based measurement of project performance and progress are Earned Value and Burndown Charts, as shown in figure 6 and figure 7. These two methods measure finished work. The measurements are based on what the team delivers, not what the team predicts it will deliver. The Earned Value is the value of the work actually completed, accumulated at fixed time intervals – measured in either currency, work hours or story points. While the Burndown Chart shows work left to do (work hours or story points) versus time.
An approach should be developed in order to optimize the project processes to achieve a successful project that satisfies expectations and needs. This means that the approach should provide the greatest chance of success. The development of a successful approach should be influenced by project characteristics, such as the level of uncertainty, the available resources and prioritized project success criteria. The uncertainty implies a degree of change, complexity, and risk. To satisfy the success criteria, necessary success factors are selected through the approach development.
Further, the developed approach should be based on a life cycle model with characteristics that match the project characteristics. Several aspects of working together, such as communication, responsibilities and decision-making, are established through the chosen project approach. The approach is always dependent on the situation, and should be open to changes during a project. It is not something you design on your own. The development of an approach is done in cooperation with important and influential key players, and the approach must be customized for each system development project.
- Better Practices of Project Management – Based on IPMA Competences 4th revised edition – 2017 – John Hermarij
- Agile Practice Guide – 2017 – PMI
- Requirement changes in IT projects – Computerworld Norge – week 47 – 2017 – Magne Jørgensen at Simula Research Laboratory
- Manifesto for Agile Software Development – 2001 – http://agilemanifesto.org/
- The Scrum Guide – 2017 – https://www.scrum.org/