Defining the scope of a project is something I have often heard referred to as “herding cats”.
All joking aside, it really is a very good analogy to the early stages of a project. It is common to see multiple stakeholders, often with different agendas and perspectives, and that’s just the stakeholders you know about. Always do a thorough stakeholder analysis before you attempt to model the scope, or you may be in for some unwelcome surprises down the road.
For the purposes of this article though, I’m going to assume you’ve done that already, because what I really want to talk to you about is scope modeling.
You don’t have to stick only to written statements to define your scope. There are a variety of models you can use that can help you capture the scope of your project. Some of those models are:
- State Diagram
- Entity Relationship Diagram
- Data-Flow Diagram
- Organizational Model
- Context Diagram
There are some very good reasons to model your scope. First of all, many people understand things better when they can see it visually. People quickly grow tired of pages of documentation, and sometimes important details get buried in paragraphs. A diagram is just faster and easier to understand. Secondly, it makes a nice compliment to any documentation that you’ve written, thereby facilitating comprehension. Throw a lot of mud at a wall, and some of it will stick.
What I like about the Context Diagram is that it’s pretty easy to grasp by almost everyone. As I’ve explained it to others, it represents who’s doing what. It is not flow. There is no sequence or timing represented in this diagram. Just interactions. This is quite useful when you’re defining scope because you generally don’t care about the sequence of things at that time. All you want to know is, what’s in and what’s out.
So to show you the Context Diagram in action, let me show you how I used it for a project I’m currently on. The project is for a research office at a university that oversees the process of applying for research funding, ensuring compliance to governing bodies, and providing reporting on the progress of ongoing research projects. They have a strategic goal to increase research funding on campus, but they are using a data system that is poorly suited to the work that they perform. They have little hope of being able to handle the increased activity that comes with meeting their strategic goal when they are using inadequate tools to do their job, so they need a new system that is better suited to their needs.
My approach to this project has been to identify which processes they wanted to be improved as a part of this project, model the current state (as-is) of these processes in a Context Diagram, then model them in their future state (to-be). Modeling the current state in this way will allow us to spot automation opportunities or other improvements, and the future state model will demonstrate how we expect the new system to affect these processes. There were three main processes the stakeholders identified to me:
- Proposal development – this is where the researcher constructs their application for research funding.
- Communicating results – after the research office receives the responses from the funding agencies in regards to which proposals have been approved and not approved, they must communicate the results to the greater research community across the university.
- Final documentation processing – Updating compliance information, entering/updating protocols, and sharing funding data with the department for research accounting.
Bringing these three processes together, I came up with the following Context Diagram representing the current state:
The square at the center of the diagram with the word CURO appearing in it is the research office. As you can see, they are the gateway for all the information that goes into their database system, Eclipse. In the left third of the image, you see the Proposal Development process. In the right third is Final Documentation Processing, and in the center is Communicating Results. How easily we can see from this diagram all the pressure on the research office, CURO, to keep this process moving. Clearly, if they want to increase their research activity, they need to alleviate some of this pressure.
Now take a look at the Context Diagram for the future state:
Notice the decrease in the number of arrows going to and from the research office, and the increase in the number of arrows going to and from the new system. This will shift some of the pressure off of the research office and onto the new system. There is also considerable interaction between the researcher and the system, so not only will the new system have to have some self-serve capabilities, but this system will have to be intuitive enough that the researcher can use the system effectively without extensive training. Last but not least, notice the second oval to the lower right. It is the student information system at use in the university, Banner. The new system is expected to pull information from Banner to reduce data inaccuracies and the amount of manual data entry that is currently required.
Putting these two diagrams together, we now have a much better idea of what the scope of this project is, and what expectations we have for a new system. These diagrams will also be used when we go through the RFP process to select a third-party vendor.
I hope I have demonstrated the value of using the Context Diagram when defining the scope of a project, however, it is not the only tool that can be used for this purpose, and in future posts I will be exploring the value of some of the other diagrams mentioned at the start of this article. Stay tuned!