The Define Phase

The Define Phase
By Josh Milane

Every major PM methodology that I am aware of: PMI (Initiation and Planning phases), Prince2 (Starting, Initiating and Planning), RUP (the Rational Unified Process calls it “Inception“) and even the Microsoft Solutions Framework (Envisioning) has a “Define” phase of some variety. They call it by different names, but the point of the project’s Define phase is the same. We need to answer the question: “What is the project about?” – in advance of development.

I want to stress the importance of Requirements Documentation (I capitalize it because it is *that* important) and the initiation of Requirements Documentation during even the early brainstorming sessions of a given project. Hopefully, you will capture the results of these brainstorming sessions, client interviews, or other early requirements processes on paper. These are not Requirements, but they become the fodder, the tools, the processes by which your Functional and System Requirements will find genesis. As an Analyst, I like to document the details of an incipient project, even if only to refer to the documentation later and examine its evolution.

I can hear you ask why it is important to examine a project’s evolution, and it is a valid question. The answer is that as projects change and as scope shifts and creeps (as it always does), it helps to understand the intent of the effort. This is often captured most clearly, albeit at times indirectly, in the early discussions that are sometimes informal, but nonetheless, critical.

Each methodology has specific documents or milestones that manifest during the Define phase. I know there probably are PMPs out there who make sure that they do each and every one, but I cant imagine a project with sufficient time, complexity, resources, and money to allow for, require, or mandate this. The aforementioned methodologies are not true methodologies that dictate our every move. They are toolboxes for methodological tools. Just like a development environment such as .NET is not a .NET application, the various “schools of thought” such as PMI or Prince2 should be viewed as environments that you look to in order to gain the tools and leverage necessary to manage and actualize your projects. In the Define Phase, we are trying to figure out what the project is about. We should use whatever tools will obviate this and make our task easier and more effective. We should do what works, as always, and do things for the sake of the project – not the sake of the Toolset.

The Define Phase is as far as I go with some clients, because the goal of our engagement is a detailed Requirements Document with UML, Use Case Diagrams, and Use Cases. I am sometimes hired to do nothing more than this, knowing that I will not be leading development and may never even speak to the development team.

Such an arrangement works well for clients, because they are able to shop the requirements around to development houses much like a person building a house can bring blueprints to different builders. A good Requirements document will allow for this. A bad Requirements document will create more work than it saves, and will potentially marry the client to a solution they do not want. This is particularly true if you start mapping MoSCoW priorities to the requirements. A requirement is always required. Scope items can have priority.

One caveat I will bring to the table and offer for consultants to consider is that rarely will a client look at a UML workflow and actually trace the lines with his/her finger, ask questions, and understand what they are looking at. It looks complicated, so they assume that the analyst/consultant knows what they are doing. This is a big mistake, although perfectly understandable. One company I worked for threw so much UML and documentation at clients that you could almost see the client tapping out, waving their white flag and yielding, writing the check for the first project payment to make that document go away. Oddly, I have rarely seen a client question Requirements documentation except for where it is written in “plain English” – such as sections describing desired user experience or sections detailing button text. It is mandatory, and part of your job as a consultant, to be sure the client understands what they are signing off on. They may not be able to follow an Object Model or to understand the system, but they can certainly make sure that their Business Requirements are captured. You may choose to start with a narrative and distill your requirements from that narrative. This can prove a valuable exercise for both the client and the consultant.

It is all too true that UML and Requirements documentation can function as misdirection. The more complicated it looks, the more most clients assume it is accurate. This is obviously far from true.

So how do we capture Requirements in a meaningful way, in a way that allows us to be sure the client agrees not just on paper but in actuality?

I am lucky in that one of the things I enjoy most is the process of taking a project, nebulous and possibly ambiguous, and wrestling it onto paper, showing the client how their ideas/needs/Requirements have manifested onto paper. It is of utmost importance that they can understand the documentation, and so they will many times wind up getting a lesson in reading UML and Use Cases. When and if they do survive that lesson, they understand and we can do as many iterations as allowed. Normally, 2 or 3 iterations is all that it takes, with the second iteration involving a few weightier issues and the third being minor adjustments.

Another much-overlooked option is to heavily annotate your UML. There are little note flags in UML 2.0 – use them. If your UML is not readable and does not communicate something to the people who are reading it, what is it for? Again, do what works for the project and the client.

And truthfully, it is not at all painful. Clients want to be sure their Business Requirements are being captured. For small businesses, the system they are building can make or break them. For all businesses, the system that the consultant has been contracted to define plays a vital role in their operations and the ROI of the engagement mandates their involvement and many times, even an emotional connection to the project.

Yes, this takes time. However, compare the cost of a well-executed Define phase with the cost of recoding a piece of software to do what was actually intended, or the cost of owning something that you do not want. There is no comparison.

The Define phase is vital. Call it what you will and ascribe to whatever school of thought that you want to, but the Define phase is the client’s intial voice, it is the consultant’s value, and it is what breathes life into a project.

Josh Milane is an IT consultant in Boston, Massachusetts with over a decade of experience in information technology management and consulting. He specializes in customizing Project Management methodologies, teaching business analysis techniques, and initiating efforts towards process standardization and best practices.