IT Project Scope Management – Mission: Possible
By The Grumpy Project Manager
Scope management is a challenging part of managing an IT project. Quite often project scope is monitored and discussed on project level. Or not actually the scope, but money and time. ‘We are behind the time table and over the budget’, is reported when in fact project’s scope has not been managed properly. Scope is considered to be difficult to define, measure and follow unlike time and money. We very seldom hear conversations like ‘…But what actually is an hour? Some hours feel so long and some go by very fast. We have had mainly these fast hours and therefore it may seem that we are behind the timetable when measured with medium kind of hours…”.
Scope changes don’t just happen, but they are made. IT project scope needs to be managed in several levels; from individual tasks to a corporate IT system scope strategy.
It is very easy to mess up project scope with continuous small ‘improvements’. This happens so that either a stakeholder asks for a bit more or a developer proposes small improvements. Usually they both have good intentions to make the solution to be developed a bit better, or they want to have what they had before or have done or seen elsewhere. A dangerous individual is a highly motivated and skilled person with very low scope awareness. She or he often wants to require or deliver a bit more than expected and so causes scope creep. As a simple example: if the original specification assumes that we make a text box to input a certain value, the improvement proposal may be changed to a combo box with an editable list of values saved to a database requiring a separate maintenance module. This kind of a changes seem very useful, but easily multiplies the scope.
Talking about scope = talking about money: ‘Instead of the planned simple text box we could make you a combo box with editable default values and a separate maintenance module!’ = ‘Instead of the planned $10 bills you could give us as many $50 bills!’. Quite often the persons who agree these ‘minor’ changes are not responsible or aware about the related costs. Quite often these changes are considered to be so small that there is no need to take those through a scope change decision process.
Projects have sub projects and the outcome of those have to be put together. If one sub-project has scope problems then other sub projects suffer from those. If the quality of one sub project is raised, then others need to raise that too. Furthermore, this may mean that the competence level of the project team needs to be raised or more expensive resources are needed more than planned.
Scope change decisions in one sub project = money decisions for this and other related sub projects.
Project’s Operating Environment
We are all surrounded by various IT software and so aware of the possibilities of IT. Based on this we have expectations for corporate IT development projects. Stakeholders often have a previous software that is to be placed with a new version or a new software, and have expectations to keep the old software even if we get a new one. Stakeholders have a certain way to work and would like to keep that. Stakeholders have a certain role and a set of skills that they want to retain. These and other similar things guide stakeholders’ behavior in IT projects. It is easy to forget what is actually needed.
Project Portfolio Management
Scope changes and quality levels of projects affect other projects. Projects are compared and their outcome used side by side. Extended scope and high quality level of one project creates expectations for other projects. Project portfolio management has to ensure that projects and project managers don’t have to have scope competition. Furthermore, projects are not lonely riders. They often utilize the same resource pool, and scope changes in one project means that other projects suffer.
Scope change decisions in one project = money and timetable decisions for all projects in the portfolio. If more than planned resources or different than planned resources are needed from a common resource pool because of scope changes then all other projects suffer.
Strategic Objectives of the Corporation
All the aforementioned scope problems can be avoided if the corporation prepares a corporate IT solution scope management strategy. The possibilities of IT are far ahead of the corporations’ needs as well as abilities to use those. A corporate IT solution scope strategy is not based on ‘what we could do’ but on ‘what do we really need to operate efficiently’. IT system development is an investment and therefore it requires strategic management. A corporation should not let individual project managers, stakeholders and developers, personal ambitions, limitless possibilities of IT or fragmented project practices guide IT project’s scope, but prepare a scope strategy. Scope is usually described to define what is included in a project. Furthermore, it should define what kind of a quality level is expected.
IT project’s scope is often considered to be very unclear; full of IT technology and integration related discussions which management thinks they cannot understand. It is not unclear, but it just has to be managed in all levels with solid scope awareness.
Many well known tools can be used for scope management. The basis is the corporate scope strategy, so that each project manager knows what kind of a scope and quality level to aim to.
- Swot-tows analysis: Identify the scope related strengths and the weaknesses of the project, and the opportunities and weaknesses of the operating environment. Analyze how to utilize the strengths and the opportunities to overcome the weaknesses and threats. During the project the SWOT factors and if the taken actions improve the situation are continuously followed.
Ishikawa/ fishbone diagram is made with the project team – developers and stakeholders – when planning or starting a project and is done with a brainstorming session. The purpose is to collect things that influence this project’s scope, but also to increase scope awareness of all the participants.
WBS: A work breakdown structures should of course be prepared for a project. The prepared diagrams should not be buried after the planning phase but used for scope management. When discussing for example the earlier mentioned text box vs. combo box a WBS diagram is very useful. When all the additional tasks are added to the diagram with a certain visible color it becomes clearer for everyone what the proposed change means.
Risk analysis: Sometimes scope changes of scope creep is mentioned as a risk in a risk list. A decent risk list contains categorized risks, and scope management should be one category. The SWOT analysis, Fishbone and WBS can be used as the source for identifying scope risks as well as to manage those.
Training: Yes, good old training is also here. Scope management training should be a part of every IT project’s kick off meeting. It should provide information about corporate IT system scope strategy, scope management in general with simple examples and the identified scope risks in this project.
Meetings & reporting: Scope management should be included in meeting agendas and reporting. Timetable and budget are usually discussed and reported, but scope often left out. As scope creep starts from individual tasks and innocent sentences like ‘why don’t we have a combo box there…’ it makes sense to make a scope check when different alternatives are discussed or changes proposed.
XX method in decision making: In this method we don’t start by evaluating possible alternatives and then make a decision. Instead we start with the first X – evaluating the problem. Only after a common agreement is reached about the problem we start thinking about the solutions to solve that problem. Making the decision after a thorough evaluation of the alternatives is the second X. The made decision can be challenged and changed only if the original problem changes. Related to scope decisions: this way we don’t discuss ‘what are the development possibilities’, but instead ‘what are the development needs’.
Proper planning: If planning and specifications are vague the result is often scope creep type called redoing. Projects have a lot of demos and several development rounds after those before we get what we want.
Monitor & control: IT project scope can be monitored and controlled. There is always a reason for scope creep. When scope is monitored in all levels it is possible to prevent scope creep.
The Grumpy Project Manager is a program manager in an international corporation and has over ten years of experience in managing R&D, IT and business development projects. You can read more from the Grumpy PM on his (or her?) blog. S/he can be contacted by email at TheGrumpyProjectManager@gmail.com.