In the begining we would like to specify what is small and medium size project:
- Small project: Has a budget of less than $100,000, a team size less than six, including team members who can be switched between this project and others on a daily basis, and a duration of less than six months.
- Medium project: Has a budget of $100,000-$500,000, a team size of six to twelve, and a duration of six months to two years.
- Large project: Has a budget over $500,000, a team size of thirteen or greater, and a duration of more than 2 years.
There seem to be two currents that push this “RUP doesn’t know small projects” perception:
1. Agile methodologies allow for fast and tight increments or phases; cut down overhead; and ensure a close relationship between developer and customer.
Agile and similar light methodologies (SCRUM, Paired Programming) are innovative and helpful in software construction. However, there is no barrier to using an Agile approach within RUP. The strength of those lighter methodologies can best be observed during the Construction phase of a new system, solution, or program; but there is still a need to manage the upstream and downstream activities of the other three phases, such as determining what needs to get done (requirements) and how the operational environment will be affected (release management). RUP does not force the use of all business disciplines across the four phases of Inception, Elaboration, Construction, and Transition. Rather, it provides an optimal framework for these activities.
2. RUP and similar guides, like the PMBOK, Software Engineering Institute’s (SEI’s) Capability Maturity Model Integrated (CMMI), or the UK’s IT Infrastructure Library (ITIL) standards impose unnecessary process overhead for smaller projects. They are really only appropriate for large projects with budgets above $10 million.
Methodologies, Bodies of Knowledge, or Maturity Models do not impose process. They do provide a foundation for assessing what needs to be done and how best to do it. The “how” part is determined by the performing organization.
The PMBOK does not dictate that all thirty-nine processes in the 2000 version or forty-four processes in the 2004 version must be used in all projects. It is a body of knowledge that provides a starting point for a variety of situations a project manager is likely to encounter. For example, it can help define what your organization’s change control process should include. Now, it is certainly true that a Project Management Professional (PMP) must be able to demonstrate adherence to PMBOK, under the purview of the Project Management Institute (PMI). The PMI offers the PMP stamp of approval so that organizations who hire these professionals can be assured that the individual understands the PMBOK. But that doesn’t mean that the individual must use everything in the PMBOK on every project!
The SEI’s Capability Maturity Model (CMM) and CMMI assess and validate an organization’s maturity on a five-point scale. It’s clearly in SEI’s purview to assess and validate what an organization does and, to a certain extent, how they do it. However, that is not the same as dictating how a “repeatable process” (level 2) must be performed in terms of process, tools, and organizational roles.
Similarly, the “spirit of RUP” — along with numerous tools that have been developed to implement RUP — fosters the idea of progressive elaboration, which is essential for incremental development. The concept is that an organization should begin design and constructing solutions as some, but not all, requirements are known. Real-world delivery is the most effective way to validate whether a feature or system is a “killer app” (e.g., the Apple iPod) or a “bust” (e.g., Coca-Cola’s New Coke, from 1984).
When applying RUP, seeking SEI CMM/CMMI assessment, or using the PMI PMBOK, the best practice is to use these guides in a systematic manner. For example, you should understand the business need (a.k.a requirements) first, beginning with essential use cases, then progressing to models based on those use cases and leveraging the power of UML as you go along.
RUP and the various tools that support it do indeed “know small projects,” and it’s up to the project manager to know how best to take advantage of those capabilities.
Based on “Using RUP to manage small projects and teams“.