With projects, as with most other things in life, only one thing is certain, and that is change. This blog talks about how to cope with change using tools like Falafel Software's ActiveFocus.

Embracing change

Many project management tools, for instance Microsoft Project, allow you plan out your projects in great detail up front, defining tasks, allocating resources, mapping out milestones and calculating finish dates and critical paths. Then the project starts and reality sets in. Things change!

An agile methodology embraces change, and approaches the project in small incremental steps, exploring, experimenting and adapting as it goes; change is expected and part of the process of delivering the right software, not just something that matches the initial requirements to the letter. You may not be fortunate enough to be working on an agile team: chances are your budget is already set, and when change happens it is a major headache, and how you manage it (or not) will define the success or failure of your endeavor.

The role of Requirements

To manage change, you have to have a good idea of what it is changing from, i.e. you need to manage your baseline. What were the assumptions, the requirements, that formed the basis of your initial project plan? When the customer or the entity funding your projects asks for something important, can you go back to your requirements and tell if this is a Change Request, something that should work differently form what was initially specified, or a completely new feature that was never even in the plan, a new Requirement?

Requirements form the contract that defines the functionality that the initial project plan timeline and estimates were based upon, and probably also form the basis of your use cases/scenarios and test cases. When discussing change, it vastly simplifies prioritization and reallocation of resources or changes to timelines, if you know what has been said before, and what the character of the change is. Now you don't have to argue about whether it was included or not, instead you can focus on deciding whether to add it into the plan and move something else out, or to change something that has not yet been implemented, or whether to defer it until a later phase. Of course, if it has already been implemented by the time the change request comes in, hopefully you are developing in small increments and this wont cause too much rework.

In order to determine whether something is a change, or a new requirement, your requirements need to be detailed. This will also help you implement the requirement and its test cases accurately too, I can not emphasize enough the importance of getting the requirements right up front. If the requirement says "Implement Order Entry", 600 hours, you are in big trouble! Now, the customer says, "Hey, I want to be able to enter my orders through EDI too", can you tell from this requirement wether that is already in the project plan or not? ActiveFocus allows you to break requirements down into sub-requirements any number of times, facilitating a top down approach, where the "Implement Order Entry" could finally end up as maybe 50 nested sub requirements, covering everything from external system interfaces to UI, performance, database and reports.

Does your tool really support Requirements?

A pure resource management tool like Microsoft Project has a couple of problems when it comes to dealing with change. First of all, you don't define requirements in Project, just Tasks. Somewhere offline your Requirements are broken down into Tasks, but Project only knows about your Tasks. Your Requirements are being managed offline in Word documents (if you are using Microsoft Office Project Server, they will be in a Sharepoint Portal). But they are still just a bunch of documents. You can view, edit, and check in and review changes to individual documents, but it is hard to work with a set of Requirements in a structured way.

ActiveFocus is an example of a tool that makes Requirements a first class citizen, not an afterthought. There are other tools that do this too, for instance Borland Caliber. In a tool like this, you can categorize, sort and filter Requirements (see ActiveFocus below - note the hierarchy of requirements to the left) :

You can also run reports and see dashboards detailing the current status of your requirements:

With this kind of tool, you can work with your requirements in structured manner, and ask questions like "what is the total remaining effort for my database related requirements?", and "How many UI requirements are complete?". Armed with this knowledge, it is easier to react to change, because you know at a very deep level where you are in the project, not the shallow level provided by knowing just which tasks are completed or not.

Another problem that faces Microsoft Project users is that it takes an expert Project user to even attempt to change and keep a large project plan up to date. I have run many projects myself, using Project to do the initial planning, only to find myself incapable of keeping the plan up to date with the project as it unfolds. Finally, at some point, you abandon the plan and start managing the project with emails, excel sheets and ad hoc messages. But now you have lost grip of the project, it is spread out, there is no dashboard, no total report, no control or focus. Sure, an expert project manager can still pull it off, but that is in spite of the tool, not thanks to it.

Other Tools that purport to support managing requirements are really just a thin veneer over a file management system. For instance, contrast the screen shots above from ActiveFocus with the Requirements view in Microsoft Team Foundation Server:

It has a hierarchy, but the elements in the hierarchy are just documents. You can't see any information about their estimated effort, who is working on then, what their current status are, which are complete, etcetera.

Just as a side note, ActiveFocus does allow you to do the kinds of things you can do in Microsoft Project and Microsoft Team Foundation Server too. You can attach any kinds of documents (Word, Excel, Visio etc) to your requirements, and then review, download and upload revisions. You can also define tasks and milestones, and assign resources to tasks (and requirements). In an upcoming version of ActiveFocus you will even be able to import your baseline project along with all of it's resources and tasks directly from Project.

The Impact of Change Requests

Now that we have established the importance of requirements as your baseline, in the next blog I will discuss how to best manage Change Requests, and how to quantify their impact on your project.