Larry Moore[5] Questions the Particular Project Boundaries
@Max: Excellent comment, as usual. Pointing out the 3 different organizational levels is very instructive and very much to the point. However (with all due respect), my take on these 3 levels is a bit different.
- Your first perspective is for the completion of the project and the delivery of the product of the project.
- Your second perspective is regarding the deployment and acceptance of the product and "transfer of care custody and control of the product," (all of which occur after the project is completed).
- Your third perspective is regarding the "effective and efficient utilization to produce the originally intended benefits." (Again, occurring well after the project is completed).
From my perspective, having dealt with all of this for decades, I believe that these three "perspectives" should really be defined as THREE SEPARATE PROJECTS, not three parts of the same project. It's all about how our projects are defined. A properly defined project must have a clear and specific completion point with which all involved parties agree. To withhold the determination of project success or failure until some undefined or poorly defined point well after the project is completed is certainly not best practice.
If the project is defined as completing the DELIVERY of a product according to requirements, on schedule, and within budgeted costs, when this is accomplished, the project is OVER and it is successful. If the project is defined to include further transitions, deployment, achieving x benefits, etc. then that is another issue. Whether a project eventually provides all of its expected benefits is a very different judgment from whether the project was or was not managed successfully. Failure to recognize this causes all kinds of problems.
@Max Wideman: I appreciate your last comment, and for many projects I completely
agree with you. However, I strongly believe that, in certain cases what might
be seen as a single project really should be separated into more than one project.
Here's an example from my own experiences with implementing new IT application
systems.
Let's say that Company A needs a new, integrated Human Resources and Payroll Management system. This requires:
- Building a Request for Proposals,
- Delivering it to multiple pre-selected vendors,
- Getting and analyzing their proposals,
- Evaluating each of the systems and vendors,
- Selecting the best fit system & vendor for Company A's needs,
- Developing, negotiating, and agreeing to a contract for the system and the vendor's implementation services,
- Delivering and installing the new software system,
- Setting up, customizing, testing, the new system,
- Training people on the use of the new system,
- Etc., etc.
In my opinion, this should NOT be defined as a single project (been there, done that and encountered all of the consequent problems). My main reason for this is, "How can I design and build an accurate and complete project plan for the implementation of a new system if I do not yet know which system is to be implemented? If all of the above activities are lumped into a single project, this will inevitably require the re-planning of the implementation part of the project, thereby wasting a lot of time and effort. If this is split into two projects, one for the evaluation, selection, and acquisition of the software and services, and one for the implementation activities, we don't have this problem.
Once the product to be implemented is known, the detailed planning for the implementation activities can be done correctly, and a great deal of time and effort will be saved. Also, should there be issues with the whole program, this allows the blame and/or correction efforts to be assigned to the correct part of the program. This also helps to assure that we will not try (and perhaps fail) to implement the wrong system.
For this HRIS/Payroll example, it can be handled as a single project with major phases, or as a major project with sub-projects, or as two or more separate projects. Any of these approaches would be proper. The worst approach would be to manage it as a single, continuous project without any major phases or sub-projects.
Mainly for accountability reasons, I favor the multiple project approach. I have been stuck with implementation projects where the wrong product or vendor has been chosen by executive management (usually without a proper evaluation, selection and acquisition plan). Then my implementation and deployment project was blamed for not providing all of the expected benefits (because the product was not a good fit for the organization in the first place).
This all brings up a very interesting issue: What are the skills and characteristics needed by a project manager to change management or executive people's minds to adopt a better methodology or approach to managing programs and/or projects? In other words, what does a project manager need in order to be an effective agent in determining proper approaches to projects, programs, etc.? I already know from experience that a large amount of courage is required to do this.
5. Larry Moore: Project Management Professional
|
Max Wideman's Thoughts for Further Discussion
