This is from an exchange on the NewGrange listserve …
When phases are called “initiating, planning, executing, and closing,” how do you know where to do requirements, design, development, testing, and turnover? If you are going to do requirements as part of initiating, why not call it that? How can you possibly plan for the development activities when you don’t even have a design in place yet? Why have a planning phase when you know that most of the planning will not be done as part of that phas
These terms only work as “phase” names when you are actually dealing with a single phase. For example, they work fine for the construction phase of a real estate development project, or for the coding and testing phase of a software development project. But they don’t work when you try to use them for a development project that’s starts with a problem statemen
In my experience, IT project teams using these phase names are forced to commit to schedules and budgets that are mostly fantasy. Management doesn’t understand why they can’t accurately predict the cost of the project at the end of the planning phase, so they try to do requirements in the initiating phase … and don’t do any real planning to support requirements. Then they squeeze their design activities into the planning “phase,” and again, they try to develop an adequately detailed design document without any real planning.
Phase names need to be product-oriented.
Tags: NewGrange, OPM3, organizational competence, phase names, pm maturity, PM methodology, PMBoK Guide, Process groups, project life cycle, Project phases, project success, SDLC
