The OIT Project Management Framework is an important guideline to use when embarking on a software development project or implementing third-party solutions. It represents set of guidelines and steps to help you navigate through the project management life cycle in OIT to deliver a successful project outcome.
The guidelines described here is meant to adapt to any project by tailoring the steps, processes, and procedures to meet specific needs of a project. For more information, see Tailoring the SDLC. An overview diagram of the entire process can be downloaded in PDF or Microsoft Visio 2010 format.
Waterfall vs Scrum
Both Waterfall and Scrum are widely used methodologies for different reasons. Although most projects adopt one methodology over the other, the non-traditional hybrid method of using parts of each methodology can also be effective in arriving at the desired project outcome. Table below provides some characteristics of both Waterfall and Scrum. Detailed information on each methodologies tailored for OIT can be found in the following links.
| Waterfall | Scrum | |
|---|---|---|
| Fundamental Assumptions | Systems are fully specifiable, predictable, and can be build through meticulous and extensive planning. | High-quality, adaptive software can be developed by small teams using principles of continuous design improvement and testing based on rapid feedback and change. |
| Control | Predictive: decisions are based on forecasts | Empirical: decisions are based on realities you observe in the actual project |
| Management Style | Command-and-control (amber organizations) | Leadership-and-collaboration (orange and green organizations) |
| Knowledge Management | Explicit | Tacit |
| Role Assignment | Individual - favors specialization | Self-organizing teams - encourages role interchangeability |
| Communication | Formal and documented | Frequent and facilitated |
| Customer's Role | Important | Critical |
| Organization of Work | Guided by architectural level and tasks (vertical slices by architectural level) | Guided by product features (horizontal slices through each architectural layer) |
| Development Model | Life cycle model | Evolutionary/Incremental delivery model |
| Desired Organizational Structure | Mechanistic (bureaucratic with high formalization) | Organic (flexible and participative, encouraging interpersonal interactions) |
When to Use Waterfall and When to Use Scrum
We recommend using Waterfall if:
- Customers know exactly what they want in advance and will not change their mind
- You know exactly what your customers want
- You know that users will have no concerns with your initial design
- Any feedback from users is either addressed in a subsequent project or not at all
- You’re working with fixed-price / fixed-bid contracts
- The project is very predictable or you’ve done similar projects many times before
- You’re working with fixed scope unchanging projects
- You anticipate only minor mistakes throughout the project
And you should use Scrum if:
- Your customer does not know exactly what they want at first or could change their mind
- You don't always know exactly what your customers want or they're needs aren't always communicated perfectly
- Your users provide feedback on your design and you'd like to act on it
- You prefer to address user feedback during the project instead of after
- The final product isn’t clearly defined at first or the definition may change
- You anticipate there will be changes in scope, requirements, opinions, priority, environment, people, or technology during the project
- Some part of the project is different or is of moderate complexity
- You want the option of closing a project early once sufficient value is created (avoiding "everything but the kitchen sink" pitfall)
When deciding between Agile versus Waterfall, it can all boil down to this: if you anticipate or expect any changes throughout the project, go with Agile. If you know the project is fixed, unchanging, and predictable, Waterfall may be a better choice.