Project execution is facing demanding requirements from customers concerning their expectations of high-quality products, with less lead time and costs.
Also, depending on the type of project, customer expectations in terms of time and costs can show strong variations between one project and another. Therefore organizations need to approach different types of projects in the most efficient manner to meet customer expectations. Consequently, it is necessary to differentiate the type of project and its life cycles and how these cycles interact with each other.
There are at least four execution models for a project:
- Sequential Execution (predictive): Single-step waterfall or traditional model.
- Concurrent Engineering (predictive, foreseeable and overlapped).
- Lean Development (predictive, adding value).
- Iterative, incremental Execution (adaptive): Agile Development (Scrum, XP, Kanban, other).
It would be advisable for organizations to approach each type of project with the most appropriate execution model from the list above. Organizations can use a different type of execution approach for each project in their portfolio. Therefore, it is necessary to identify which model is best applied to a specific project, so it will also be necessary to know the fundamentals of each model, its strengths, and weaknesses. Accordingly, each of these models is described below with its advantages and disadvantages.
Sequential Execution (Waterfall or Traditional Model)
Sequential Execution model (Waterfall development or traditional execution) is a non-iterative approach in which progress is flowing steadily downwards (like a waterfall) through the project life cycle (conception, initiation, analysis, design, construction, testing, production/implementation, and maintenance). Sequencing of tasks lead to a final deliverable, and the work is done in that order. One task must be completed in a connected sequence of items before the next one begins that will add up to the overall deliverables. The phases do not overlap, and phases are completed one at a time.
- The model is simple and easy to use.
- Every step is preplanned and laid out in the proper sequence.
- It is an ideal method for projects that result in physical objects (buildings, computers).
- Project plans can be easily replicated for future use.
- As the methodology is quite rigid, it is easy to manage it because every phase consists of a review process and specific deliverables.
- Waterfall development methodologies are good for small projects that contain clear requirements.
- Relying on the method Waterfall, your customers know what to expect. They will get an idea of the cost, size, and timeline for their projects.
- If a company has employee turnover, the strong documentation allows for a minimal project impact.
- While this may be the simplest method to implement initially, any changes in customers’ needs or priorities will disrupt the sequence of tasks, making it tough to manage.
- Designers often are not able to foresee problems that will arise out of the implementation of their designs.
- Real projects rarely follow the sequential flow and iterations in this model are handled indirectly. These changes can cause confusion as the project proceeds.
- It is often difficult to get customer requirements explicitly. Thus specifications cannot be frozen.
- Changes to requirements cannot be easily incorporated, and there are often difficult change control procedures to go through when this happens.
- Even a small shift in any previous stage can cause a big problem for subsequent phases as all phases are dependent on each other.
- Re-work in a phase can be a costly affair.
Concurrent Engineering approach comes mainly from the aerospace industry, and its basic premise revolves around two concepts. The first is the idea that all elements of project life cycle should be taken into careful consideration in the early design phases, together with initial contact with suppliers. That is, handling in advance at early project stages the downstream concerns. The second concept is that the preceding design activities should all be occurring at the same time, i.e., concurrently. The idea is that the concurrent nature of these processes significantly increases productivity and product quality.
Biren Prasad in his remarkable work “Concurrent Engineering Fundamentals, Volume I: Integrated Product and Process Organization” described, among others, the following fundamental principles of concurrent engineering:
- Early Problem Discovery
- Early Decision Making
- Work Structuring
- Teamwork Affinity
- Knowledge Leveraging
- Common Understanding
- Faster product development.
- Maximize product quality, by spending more time and money initially in the design cycle and ensuring that the concept selection is optimized.
- Increased productivity.
- Collaborative decision making.
- Teamwork, Human Resources are working together for a common product.
- Information Sharing.
- This approach reduces Long-Term costs.
- Reduces Development Time.
- Reduces Design Rework.
- Large Upfront Investment.
- The decision of beginning components without the required information creates potential risks for project changes and rework.
- Poor planning and lack of prudence can drive to poor decisions based on wrong assumptions, all of which can have negative impacts in project execution leading to rework and delays, and ultimately to increased costs.
- Dependency on Efficient Communication. Poor communication is more likely to lead to disaster.
Lean Development approach comes from Japanese automotive industry, and essentially it is focused on making what adds value from the customer’s perspective reducing the waste. That is, the continual process to increase the amount of valid engineering data produced per time and money invested.
Lean execution is based on:
- Focus on the end purpose.
- Determine the workflow.
- Eliminate waste.
- Test the project.
- Empower the team.
- Identify Value.
- Map the Value Stream.
- Create Flow.
- Establish Pull.
- Seek Perfection.
- Increases organization productivity and efficiency.
- Avoids wasted motion.
- Increases safety.
- Eliminates unnecessary production.
- Reduced engineering lead time.
- Offer improvements at an inexpensive cost.
- The introduction of lean design principles in the design phase can be complicated and lengthy.
- Diagnosing and identifying the level of waste in the process and the causes usually take extensive periods of time and effort.
Agile Framework (Scrum, XP, Kanban, Crystal, Other)
The Agile approach comes from software development environment, and it promotes an incremental delivery model rejecting any predictability and long-term planning instead.
For Agile project management, the customer value is a number-one priority, and so the entire iterative process is organized and managed around customer value. This approach requires that a small, highly-collaborative team be involved in the product development life-cycle and they collaborate on product changes, improvements, and additional features during short sessions. “Change” is considered the driving force of team collaboration, and so it should be embedded into the Agile process to let the team explore improvement opportunities and work on tailoring the product to its business purpose.
The most evident benefit of Agile-driven product delivery is that you discover how your project is being done very early at any stage of the development life-cycle. Lean-Agile project management promotes a non-deterministic process in which you can use regular iterations to align the product with client needs. In contrast, traditional project management tells you nothing about the quality of your product until your dev team enters the test phase, which is usually scheduled for the project’s end. Agile means:
- Individuals and interactions instead of processes and tools.
- Working software instead of comprehensive documentation.
- Customer collaboration instead of contract negotiation.
- Responding to change instead of following a plan.
- Higher customer Satisfaction.
- There is closer collaboration between developers and the business.
- Changes to requirements can be incorporated at any point in the process, even late in development. It gives the opportunity for continuous improvement for live systems.
- Increased productivity.
- Reduced risk.
- Customer feedback loop.
- Visibility & Accountability.
- Increased quality.
- Can be very demanding on the user’s time.
- Harder for new team members to integrate into the team.
- Costs can Increase as test are required all the time instead of at the end.
- Agile can be intense for the team.
- This method is especially bad in the case of insufficient client feedback.
- Agile methodologies are often harder to understand than linear, sequential ones, at least initially.
- Because of the emphasis on working software, there can be a perception that documentation can sometimes be neglected. The focus should be on appropriate documentation to the audience that needs it but, if not implemented well, this is not always the case.
- When implemented badly Agile can introduce extra inefficiencies in large organizations or can be working against long-standing organizational processes.
- Active user involvement and close collaboration are required throughout the development cycle.
- All the team should work in the same location.
- Flexibility Can Lead to Bad Behaviors.
- Lack of Predictability
- Scope creep risk.
Table 1. Execution models versus some key project constraints
|Key Project Constraints||Waterfall||Concurrent||Lean||Agile|
|Deadline Compliance (schedule)||Medium||High||High-Medium||Low|
|Scope compliance||Excellent||Good||Good||Good, but there is scope creep risk|
|Required team experience (resources)||Low||High||Low-Medium||High|
|Customer /Stakeholder feedback||Low||Low||Low||High|
|Communication level required||Low||High||Medium||High|
Table 2. Execution models versus some key project characteristics.
|Key Project Characteristic||Waterfall||Concurrent||Lean||Agile|
|Planning||Detailed||Detailed||Detailed||Developed by Iteration|
|Plan updating frequency||End of each phase||End of each phase||End of each phase||Short periods (e.g. Weekly)|
Table 3. Some project type and recommended execution models
|Small projects with clear requirements||x|
|Projects that result in physical objects||x|
|Projects with fixed scope and fixed price contract||x|
|Restricted projects in time||x|
|Restricted projects in budget||x|
|Software innovation projects||x|
|Long term projects||x|
|Automotive industry project||x|
|IT development projects||x|
|Projects that requires early procurement||x|
|Heavily restricted projects in time and budget||x|
|Projects with scope not well defined||x|