Are you interested in DIY? Many house owners discover a flair for this through necessity. It can be extremely rewarding to solve a problem around the home without calling in the experts. However, every DIY task is, in itself, a project and as such needs to have its scope defined.

On this page:

• Defining Scope in DIY Projects
• Lessons from Project Scope Management
• Investigating the Task at Hand
• Planning Project Scope Management
• Collecting Requirements
• Setting Boundaries and Demarcation
• Work Breakdown Structure and Requirements Traceability Matrix
• Managing Changes and Validation
• Conclusion

Defining Scope in DIY Projects

But surely something as straightforward as a dripping tap does not require any thoughts of scope – you just need to fix it. However, you need to decide what needs fixing: Is the whole tap faulty, or is it just a worn O-ring? Have you the tools necessary to remove the tap and disassemble it? What will you discover when you search for the stop valve or gain access to the tap itself? You might encounter rotten timbers or a nest of mice that needs to be removed. DIY tasks tend to grow legs – or, as project managers say, they suffer from scope creep.

Lessons from Project Scope Management

Taking lessons from Project Scope Management can save a lot of grief. We need to have clear requirements: The tap must be made to stop dripping. Okay, so how are we going to do this? Well, we need to decide first off if this is a job we are capable of doing. Tradesmen are the DIY enthusiasts’ biggest fans because they regularly overstretch themselves and end up calling in the experts before their partners arrive home and find a swimming pool where the kitchen should be.

Investigating the Task at Hand

Then we need to investigate the offending tap to find out what needs to be replaced or repaired. This involves cutting off the water supply and removing the tap. At this point we can decide is it a part or the entire tap that needs replacing. We are now also in a position to place what we need on the counter of the plumbing providers and ask for one of those. So fixing the tap involves:

Buying parts
Installing parts
Testing the new parts
Replacing everything that was removed in order to access the tap and stop valve.

However, note the work that was needed prior to the fixing project:

Find the stop valve
Remove the tap
Disassemble the tap
Ascertain what needs to be done.

In other words, projects often need significant investigation before we can safely state what we are going to do. This is why project managers should involve the project team in planning activities. S/he can send team members off to investigate specific parts of the projects to determine exactly what needs to be done.

Planning Project Scope Management

Formally speaking, Project Scope Management itself needs to be planned. How are we going to define the project’s scope and how are we going to ensure that we deliver what we are promising? We will need to create both a Scope Management Plan and a Requirements Management Plan. The easiest way to explain these plans is to look at the work involved in Project Scope Management.

Collecting Requirements

The next step is to Collect Requirements. These are what the customer requires. In our example, the tap needs to stop dripping. How we achieve this is not defined in the requirements. This is actually a serious issue for project managers. Often, customers offer solutions, and the requirement gets expressed as: replace the O-ring on the tap. A requirement needs to reflect a problem. This makes the dripping tap an acceptable requirement. It will either drip or it won’t; if it does not drip, the project is a success! We can demonstrate this by sitting our stakeholders by the tap and having them observe the drip (or, hopefully, the lack of one). However, in situations where we have lots of requirements, it might be useful to practice requirements triage.

Once we are clear on the requirements, we need to Define Scope. This is where we define the solution to the problem. Now we need to ensure that our requirements are measurable and testable. This might involve clarifying the customer’s original requirements by detailing the characteristics of the proposed solution. Obviously, the customer will need to agree with our revisions before we can proceed.

Setting Boundaries and Demarcation

Another key step is to make explicit what we will and will not do. For instance, tradespeople are very insistent on lines of demarcation. A plumber will not do carpentry or electrical work and the other trades make sure they do not do work another tradesperson should do. In our example, this means that a plumber would say: I will fix the tap and repair any defective pipes I see, but I will not replace rotten timber or remove animals from under the bath. Defining scope is a really useful exercise, because it makes explicit the boundaries of the project. Telling the customer exactly what we are planning to do can expose tacit assumptions and brings out additional requirements. Discovering these at the start of a project means that we can charge extra for them!

Work Breakdown Structure and Requirements Traceability Matrix

The final part of the planning work is to create a Work Breakdown Structure, which is a graphical representation of the project’s scope. This takes the requirements and breaks them down into deliverables. We have done this already in our tap example, where we need to source a new part, replace the old one, reinstall, test and tidy up. Sourcing the new part might involve locating places that might sell these items, ringing them up (if we can describe them over the phone), and visiting the shops.

This is a useful exercise as it encourages the team to consider all the work needed for each requirement. As well as a Work Breakdown Structure, we should also produce a Requirements Traceability Matrix. This maps the requirements onto the work packages given in the Work Breakdown Structure. When the work is done, the requirement should be met. This work should include measuring and testing, so we can demonstrate that the requirement has been reached.

Managing Changes and Validation

During the project, other work might appear. We might discover a leak near the stop valve and decide to fix that as well. This might involve buying other parts and, again, it might involve bending pipe or flaring ends that we are not able for, so we would need outside help. Any change from the original scope needs to be considered carefully. If it involves spending more time or money, the payback must be worth it. For instance, if the original tap is in an awkward place and a lot of work is required to gain access, it does become cost-effective to deal with any issues exposed during the job. However, if the change does not relate to the work being done, it might be best to leave it for another day (or another project).

Finally, we need to show that we are finished. This is called Validate Scope and it simply involves demonstrating to the customer that the requirements have been met. In our example, showing a tap that is not dripping is sufficient. In more complicated projects, the customer may wish to see evidence of the process followed and how each work package was completed. The Requirements Traceability Matrix will help this effort.

Conclusion

If we return to the plans for a minute, we can now see that the Scope Management Plan tells us how to define the scope and how to manage change, whereas the Requirements Management Plan tells us what to put in the Requirements Traceability Matrix and how to demonstrate completion to the customer.