Editors Note:
A "Dialogue on the Right PM Method" is an email exchange between Max Wideman and Gordon MacMaster on Choosing the Right PM Method and a particular discussion of the Rational Unified Process Methodology (RUP). For readers who may not be familiar with the RUP here is a short definition of this software development process.
Max Wideman sent an email to Gordon MacMaster...
Subject: PM Method
Dear Gordon:
I have just read your article "Choosing the Right PM Method" in the March 2002 PMnetwork, p49. I was struck by your comment "Many methodologies contain elements of both product and project management. However, without a clear distinction, Project Managers may believe that by managing the details of the product they are actually managing the project."
Exactly so! Do you then subscribe to the view that there should be a clear distinction, in PM education at least, between project management (i.e. management of the PM process) and product management (i.e. management of the technology)?
And what in fact are the different methodologies to which you refer?
MW.
PS the article I refer to is also on your web site (whence I got your Email address)
Gordon MacMaster replied...
Yes, I do agree that there should be a clear distinction, in education and practice, between Project Management and product development. In fact, I think a significant source of failure for IT projects is the inability to see a difference between the two.
The blind spot, I believe, is because there are two main "schools" regarding project management for IT. The first school believes you have to rise up through the technical ranks - technical ability is a significant success factor as a project manager. The second school believes a project is a project, regardless of what you are building - the management techniques and challenges are the same.
If an organization's culture is of the first school, I find Project Managers tend to be technically capable but regard PM processes as 'administration' that is dropped in times of crisis. The second school tends to focus too much on process and often create one size fits all methodologies that are not appropriate for all types of products and product development approaches. Well managed processes can still turn out crappy products.
When an organization views product and project as separate, and put in place the right people and complimentary techniques for project management and product development, the potential to succeed is enormous. But it is a tough balancing act with really no magic formula (none that I found anyway - otherwise I would be a far wealthier individual).
The methodologies I am referring to are the ones I have come into contact with during my brief consulting career. An excellent example to illustrate what I am talking about is the Rational Unified Process (RUP). RUP has several workflows for software development one of which is Project Management. The PM Workflow consists of a few deliverables, primarily a software development plan and a risk management plan. Since PM is included as a workflow, most people see RUP as covering both product development and project management. However, it is completely insufficient to manage a project. In truth, RUP is a product development methodology. I think they should drop their Project Management deliverables and simply state - Find a Project Management approach and plug it in this workflow.
I have not updated my website . The article there is the original that I wrote and submitted to PMI. I was (if I ever had a chance) going to post the PMI version of the article in its place. That is what the person I was speaking to at PMI suggested I do.
Thanks for the feedback. It is nice to know people are reading your material.
PS - I have read your book on Risk Management as well.
Max replied...
Gordon:
Interesting comment about RUP. If you have time, you may want to visit
http://www.therationaledge.com/content/dec_02/m_progressiveAcqRUP_mw.jsp .......(1)
On "I think they should drop their Project Management deliverables and simply state - Find a Project Management approach and plug it in this workflow. " the problem is that I don't think just any PM methodology will do. It requires a *particular* PM methodology - one which is only just beginning to surface in the literature. (And I don't mean Agile or Extreme programming which is a *product* leave-us-alone-to-get-on-with-it methodology!)
M.
Gordon Continued...
Max,
I will visit your article. I have worked on three initiatives that use RUP. All three found the Project Management portion insufficient. However, there was not a PM methodology that lent itself to be plugged in very easily.
My observation is based on the experience of using RUP. You are right, they do need a particular methodology - I am just not sure they should be the ones creating it. I led the development of a PM Methodology for my current client which is using RUP. So far, it has worked rather well. We have made numerous discoveries some of which include:
Much more effort was needed in project planning, tracking and status reporting than the client expected (here the iterations are on a two month cycle). The flexibility of the RUP approach is only useful if you are on top of events and can make decisions quickly. Tracking and reporting systems that lag by greater than a week was simply not enough. A much stronger project office than the client is used to having was needed to fulfill this role.
In relation to flexibility, decision making had to be pushed down to be able to use RUP effectively. We developed clear guidelines (and a simple Web tool) to help with determining when a task or event falls under a particular person's domain. It freed up the senior management a lot, and allowed them to focus more on direction rather than micro-managing the project. Clearly empowering the Team Leaders allowed them a lot of flexibility with shifting work around within an Iteration.
Using RUP and coordinating with other groups that are not using RUP led to a lot of difficulty. Mostly it was perception problems. Many groups complained RUP and their approach were incompatible. In truth, any methodology boils down to delivery dates for deliverables. Hammering out and monitoring the dependencies with other groups was a full time job for a team. RUP, actually most methodologies, do not adequately address working with groups that you are dependent upon but are outside your direct command and control.
And you are also right, extreme programming is just an excuse to drop "administration" - I've heard the argument used many times - usually by Project Managers from the technical school.
Gordon
Editors Note:
Reference 1. Progressive Acquisition and the RUP - Part 1 - Defining the Problem and Common Terminology - Max Wideman
The Rational Unified Process or "RUP" as it is referred to, is a software engineering process that provides a disciplined approach to assigning tasks and responsibilities for purposes of software development. The RUP has two dimensions:
The first dimension represents the dynamic aspect of the process as it is enacted, and is expressed in terms of project life span phases, iterations, and milestones. The second dimension represents the technological aspect of the process. That is, the process components, disciplines, activities, workflows, artifacts, and roles. The effort varies over time. For example, in early iterations, we spend more time on requirements, and in later iterations we spend more time on implementation.
The goal of the RUP is to ensure the production of high-quality software
that meets the needs of its end users within a predictable schedule and budget.
When adopted by both software acquirers and developers it ensures uniformity
of method and ease of communication between the parties.
Gordon MacMaster |
R. Max Wideman |