Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
One of the challenges during IT process improvement projects, or any project for that matter, is to stay focused.
During the course of a project, opportunities and risks constantly surface that people tend to want to address ad hoc. The challenge is that projects should have a goal from which resources including time, people, technology and money are assigned.
By adding new tasks and objectives to the project, the defined scope of the project begins to grow. As a result scheduled dates are missed, budgets blown and there is a failure to meet expectations. To avoid scope creep and keep the project focused, there are some straightforward techniques that must be leveraged.
Bear in mind that there will always be pressures to expand the scope of projects from clients, vendors, management, and from within the project team itself. The other aspect to consider is that many of the changes make sense. Thus, the objective isn’t to create static frozen plans, but rather to manage the changes such that the stakeholders know what is going on, expectations are properly managed and the projects are ultimately successful.
In this article, we will cover two methods to better manage change — a formalized change management process, the use of “parking lots,” and risk management.
A Formal Change Management Process
By virtue of what a project is, the majority of change requests can be reviewed prior to implementation. When dealing with clients, be they internal or external, there exists a very real need to document changes and move away from cocktail napkins, emails, phone calls, faxes and in-the-hall banter as a means to communicate changes.
Instead, there should be a formal “request for change” form that is completed and, depending on the scale of the organization, sent either to the change manager or project manager for review to ensure it is complete and makes sense at a high level.
Change requests that make it past this initial scrutiny should be investigated further to determine resource requirements, costs, time frames, risks, etc. This is then presented to a change advisory board (CAB) consisting of the project sponsor and other key stakeholders who have a vested interest in the project, its success and the allocation of resources. They then make decisions about what changes to allow outright, or to reject, or to send back for further investigation. This allows all of the parties a chance to review and understand the change in the context of all the work and other changes going on.
For a good review of change management, refer to the ITIL Service Support volume and review how they handle changes for production IT infrastructure. The process is directly transferable to project management.
Risk Management
This must be a fundamental part of change management and is so important that it has its own section. Risk management entails the discovery of risk events, determining their probability, impact and to then take appropriate mitigating action to offset the risk. It may mean that a change is feasible, not feasible or that additional controls must be inserted both in the project as well as part of the deliverables to create a reasonable assurance of success.
By doing this in a project, it allows more opportunity to review various scenarios and to develop responses that are both economical and efficient. In contrast, if a risk event does occur and there has been little to no planning, there may be limited time to review options. As a result, a far from ideal option may inadvertently be selected that blows the budget, schedules, and overall expectations – in short, could cause the project to fail.
Parking Lots
As mentioned, opportunities for process improvement and/or additional work that is clearly outside the scope of the current project tend to turn up frequently. If these new topics are absorbed into the project, the scope creeps along with schedules and budgets.
The idea is to have a place to store ideas for future investigation. A term the author ran into long ago referring to this list is the “parking lot.” In the same way that drivers park their cars in a parking lot only to come back, find and use them, the same is true for projects, teams and overall organizations.
The intent is to save the opportunities, because they might make a lot of sense to pursue later and/or with a different team in parallel, and more importantly, the person presenting them gets the gratification of seeing his/her idea in writing and knowing it will be reviewed versus simply being dismissed as out of scope. Part of each project’s status report to senior management should include items in the parking lot and during the project closeout phase, a parking lot document should be sent to each stakeholder for review and feedback.
In summary, rather than allow scope to creep in an uncontrolled manner, processes must be put in place to manage change and risks. Furthermore, opportunities that are clearly outside of the current project’s scope should be put into a parking lot for further review.
These days, IT has a lot of pressures and expectations to face. To meet these pressures, IT project teams must take great care to stay focused.
