How do you decompose your analysis?

I was reminded today of a discussion that a co-worker and I were having a while back with some Business Analysts and Project Managers who worked in other Project Management groups within our company (we have several).

We were discussing the ways our different groups approached basic project documentation such as Project Charters, Business Cases, and various Requirements documents; the various “levels” of information that the documents contained; and what those “levels” were called.

It soon became obvious that the different groups didn’t always decompose their project and analysis efforts using the same terms and “levels”.

Rather than trying to explain that concept more, I’ll instead demonstrate how I prefer to decompose a project and analysis effort so that you can actually see what I mean.

This is simplified and leaves out some things that get conditionally added based on the project, but my basic set of terms and “levels” are:

 

Objectives:  The highest level of project abstraction, these state “what do we want to achieve”.  For example, “Our objective is for our team to score more points in football (American soccer).”  If an objective is measurable, it’s often only vaguely.

Which decompose into

Goals:  The next level of project abstraction, these state “how will we know we achieved our objective”. For example, “We score points by getting the ball into the opponents goal area (net)”.  It’s a specifically measurable achievement.

Which decompose into

High Level Requirements:  To achieve our goals, we need to decide what capabilities, at a high level, we need to have or the organization / market / environment conditions we must achieve.

Which decompose into

User Stories:  To define the capabilities specified in the High-level requirements in more detail, we have to define what general functionalities are needed and why. This can be done easily with user stories, even in a non-Agile project.

Which decompose into

User Interface Requirements:  If the interface is something I can control as part of my solution, the next level of decomposition is to define user interfaces that support all of the functionalities specified by the user stories at a reasonable level of detail (usually wireframes). This helps to get feedback on interface design and to start building acceptance of the solution concept as early as possible.

Which decompose into

Use Cases:  Once the interface is largely defined, I find Use Cases to be useful in identifying user and screen flows, functional options, error messages and triggers, security functions, and the many more detailed functions and workflows needed by the user.

Which decompose into

Functional Requirements, Data Requirements, and Non-Functional Requirements:  Lastly, from the Use Cases I can define the functional, data, and non-functional requirements in detail.  These are usually the lowest level of project analysis information before you start getting into technical design specifications.

 

Of course, this is a “preferred” path through decomposition and not always available.  And yes, it probably seems very documentation heavy.   But I work almost exclusively on very large strategic projects where there are usually multiple systems, multiple data stores, multiple processes, and multiple stakeholders involved; and when we are doing development rather than off-the-shelf software, a high-level of documented analysis up-front has so far proven to be invaluable in my opinion.  Indeed, I suspect that we actually don’t do enough analysis and documentation up-front in many cases.  But as they say, you’re mileage may vary and what works best for you may be radically different.

What my colleague and I discovered in our conversation is that different project groups used different terms, didn’t use certain steps at all, or had added much more system design steps into their project decomposition strategies.  Partly this was due to the different environments in which they worked (some are focused heavily on a few functions or systems), partly it was due to individual experience and preference, and partly it was just due to the way they thought of the project and analysis process.

So what is your approach?  Do you use different terms?  Do you add different “levels”?  Chime in with your thoughts in the comments, if you are willing to share.

 

Leave a Reply

Your email address will not be published. Required fields are marked *