Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Scope Management
I find if extremely frustrating when last minute changes threaten to change the scope of the project. Even after the appropriate sign off forms have been completed and the the proper channels were used to accomoplish the task at hand, there are others who find it very easy to say, "oh....we need to change our approach."
I understand that last minute changes are inevitable, however, too many people find it too easy to bombard the PM with changes. This is why we have a process in place to avoid issues like these. Properly documented project plans, sign offs, etc., help to curb these kind of problems.
I realize for a PM to have the capability to adapt to change and make intelligent choices/decisions helps to minimize an unwanted or unrealistic request, however, it is too bad that many people don't understand the importance of procedure.
Sort By:
Page: 1 2 next>
It's particularly hard to do when it's your client who is asking for the change. That sure can put you between a rock and a hard place in a hurry with your own management.
The business of PM can be detremental to ones mental well being. One item that really gets me is the sales force. They go and sell, sell, sell. Good for them. But what commitments do they make in the area of delivery, costs etc. that affect the delivery process for the product or service. The PM must be part of the final stage of closing the sale to establish an understanding of the customer's expectations and establish a frame work the customer understnds of the delivery process and the time it will take. I can not count the times I was handed a project, reviewed the bid sheet and what was signed by the customer for cost and time, then headed full steam to the salesperson and cried "You sold this, for this cost, to be done in this time frame! You idiot. There is no way this will be done for this cost or time line."

We've probably all had the experience of delivering on what someone else has sold -- not fun! In my company, we now REQUIRE that every sales opportunity is staffed by a "twinned" team, consisting of one Business Development Principal AND one Delivery Principal (the guy or gal who'll have to deliver what is sold). This has worked very well, as it eliminates any confusion regarding the deal's scope, timeframes, etc. When there is not the luxury of having a balanced sales "team" on the deal, it's always good to feed the sales force all of the tools that might help them to properly scope the project -- estimating metrics and any other approach-related information will help the salesperson to more intelligently represent your PM capabilities during the sale effort.

I agree with your approach completely Nan! Unfortunately, we have received a significant amount of resistance to this approach from the sales teams due to the additional "cost" of this delivery resource.

My belief is that we need to bring the goals and the measures of both the sales and delivery organizations closer together so there is more support between them.

Has anyone been able to create an effective solution to these issues?
The "solution" seems to be enlightened management, as exemplified in a previous post. Of course, the problem then becomes how to facilitate management's enlightenment. This is just a thought, but one key might be to sell the "enlightened" approach as a margin improvement program. Present the issue as, "how much would you spend now to improve margins by five percentage points?"
I'm not selling this as a magic bullet, naturally. But management won't move on the issue unless they see it as hurting the bottom line.
We have the problem where we don't know what project manager will be on a project when we sell it (It depends on who rolls off a project when the new project starts). Another problem is that even if we do know what PM will be available, the sale may involve a technology or 3rd party tool that the PM is not familure with. We've combatted these problems by having subject matter experts (SMEs). They are involved with the sales process and keep the project "doable".
We try to do our proposals in phases. Since the customer may not know the full scope of the project, it is very risky for both sides to make a determination up front. The only decent deal is on the requirements and specifications. After that, ideally there is a go/no go decision point based on the proposed cost of implementation.

It is also important to have a formal change management methodology with really scary PMs, to avoid "scope creep". It is hard for those of us who grew up with T&M development to adapt to the severity of change management in fixed price/hard delivery date projects.
At my company, like Nan's, we have the requirement for the delivery team to be involved with the sales person before we can make a pitch and price to a customer. As for the cost of the delivrey resource, well, when we are making a bid/no-bid decision, we decide how much it will cost to bid, make a calculation as to how much margin there is on the deal, what the chance of winning is, and then make a decision based on a cost/benefit basis. It works wonderfully, compared to the other companies I have worked in where the sales people dump undeliverable projects on the poor project manager!
Getting back to Michael's original topic of the impact of change requests on the PM's attempts to manage project scope, I think that responsibility for dealing with Change Requests should not rest solely with the PM, and should certainly not be detrimental to their mental health.

Assuming that you have a signed-off design or specification document, you need to put a proper change control process in place to help you control and balance the Cost/Time/Functionality triangle.

A Change Control committee should be formed, which should include the PM, Business Sponsors, and whoever is ultimately funding the project (if this is not the sponsors).

Anyone who wants to request a change should be required to fill out a change request form (could be paper-based or a simple Access or Notes DB) with the precise details of their change. The PM will periodically review all the Change Requests received and quantify each one in terms of cost and/or time impact and make a recommendation as to whether the change should be accepted.

Then the Change Control committee can meet and decide to approve or reject each change request with the full knowledge of the impact this will have on the project. If the project budget/timescale is blown because too many change requests were approved, then the PM cannot be held responsible.

I have also noticed that having a process like this in place tends to discourage people from making unnecessary last minute changes.
On the topic of changes that threaten the scope of the project and change management procedures...I see the "problem" of change requests as in actuality a real opportunity not only to manage change, but also through that, to manage client expectations. One way to do this is to lay out the options and consequences, and let the client choose. We typically tell the client - "OK, you want this change? Here's what it will take. In the triangle of time, resoures, and money, it will require four additional weeks, 160 additional developer hours, 40 additional Project Management hours, and therefore, $29,400 dollars additional." That gives the client the information s/he needs in order to evaluate whether that change is worthwhile.
Page: 1 2 next>  

Please login or join to reply

Content ID:

"Life is but a walking shadow, a poor player that struts and frets his hour upon the stage and then is heard of no more. It is a tale told by an idiot, full of sound and fury, signifying nothing."

- William Shakespeare