Thursday, 22 October 2015

Project Management CRM Best Practices - Managing Scope

This is the continuation of a series of posts regarding the Project Management CRM best practices.

Today I will write about how to manage scope.
After the Procedures definition has been set (see my previous post about Procedures), we can start to managing the scope.

On a perfect world we need to ensure that the sponsor approves scope-change requests, otherwise is my opinion to set dates to automatically consider them as approved past a few days if we don't have any answer from the customer side.

After the basics of managing the schedule, managing scope is the most important activity required to control a project. Many project failures are not caused by problems with estimating or team skill sets but by the project team working on major and minor deliverable because the team is working in parallel projects for other clients and when they come back they don't know what to do, or just because is not part of the original project definition or business requirements. Even if you have good scope-management procedures you need to avoid the Organization/Agency to hijack your resources for other projects.
 There are still two major areas of scope-change management to be successful, one is to understand who the customer is and scope creep.
Most of the times the project sponsor is the person who is funding the project. In CRM case it could start from Marketing, Sales, or even CFO, rally will start from CIO unless there's a huge infrastructure project that need to be changed, too many databases, excels, or even integration with Microsoft Exchange etc, Although there is usually just one sponsor, a big project can have many stakeholders, or people who are impacted by the project, here is the hard part sometimes is not clear that in fact that stakeholders is the one we should be talking too, because he thinks we his the stockholder but is not, in this case take care, listen what he have to say and validate all the inputs with the sponsor, politics can be problematic and has to be well managed. So all the requests for scope changes will most often come from stakeholders, many of whom may be managers in their own right. One manager might want workflow that sends emails automatically to his team because there`s new leads. Another might want an exception to in certain leads will receive email. It doesn't matter how important a change is to a stakeholder, they can't make scope-change decisions, and they can't give your team the approval to make the change. So you need to define a common ground and sometimes the decision "advise" need to come from you, in proper scope-change management, the sponsor (or a designate) must give the approval, since they are the only ones who can add funding to cover the changes and know if the project impact is acceptable.

There is no project that scope din`t creep, most of them cause by the time spend on the analysis, time we had to do the scope, stakeholders changed their minds, etc. Most of the project managers know to invoke scope-change management procedures if they are asked to add a major new function or a major new deliverable, just because the we need to develop a new plugin because the business rule or one of the roll-ups dint answer the need we had with calculations. However, sometimes the project manager doesn't recognize the small scope changes that get added over time. What we consider as a scope creep is the fact we have a series of small scope changes that are made to the project without scope-change management procedures being used, just because we consider its a small change and none of which appear to affect the project individually. But in matter of fact this can grow and can accumulate a significant overall impact on the project. Many projects fail because of scope creep, and the project manager needs to be diligent in guarding against it. The scope creep, allows also the business to say that the deliverable is not done causing delays on the project, and the adoption are not done by the business.. and at the end the project fails because no one is using it.

1 comment:

  1. Share great information about your blog , Blog really helpful for us . We read your blog , share most useful information in blog . Thanks for share your blog here .
    Agile Project Management