Blog Archives
PRINCE2 Product Based Planning for Business Analyst Team Leads
In the past I've very clearly wanted to separate my work as a business analyst from that of the project manager. I thought that by not writing product descriptions the project manager was being lazy and not doing his or her job. However over time, I've come to realise that by getting me heavily involved in planning the work, I have a sense of ownership and I can shape the expectations of management as to what the work involves and how long it will take. These days I willingly compose product breakdown diagrams, product flow diagrams and product descriptions.
Now rather than being incensed by having to compose these critical documents, I enjoy the act of shaping them, knowing that as I do so, I'm helping to reduce the ambiguity of the project. You don't need a formal PRINCE2 qualification to be able to construct these documents, but you do need to understand product-based planning (Chapter 21 of the manual Managing Successful Projects with PRINCE2* ).
Product-based Planning
Product-based planning is a way to understand the constituent elements that make up an end deliverable (product) that you're producing. Because it's a methodology, the PRINCE2 manual gives very clear guidance for composing product diagrams and descriptions. I won't repeat that advice here, instead I'll provide a brief introduction to the different elements used within product based planning. Hopefully it will be useful in your next planning session with your team.
Product Breakdown Structure
Start by identifying the end product that you want to do. For a lead business analyst this might be a requirements document or the completed analysis component. The identify the sub products that are needed to deliver that end product. You can also include any checks, reviews or supporting documentation that you might need to do to get to that finished product. Supporting documentation can be included even if its not in the final deliverable. For example on a past project I was involved in, the end goal was to produce a short options paper for the executive to make a decision on. My colleagues and I had to do a considerable amount of documentation and planning to get enough analysis that we could summarise it into the desired format.
Product Description
I love product descriptions because they provide clarity for everyone on the team as to what and how is being produced. There should be enough clear guidance that by looking at a product description a team member knows exactly how to go about their work. This is enhanced even further if there is a development methodology in place because that should help guide the product description creation or fill in any gaps.
Product Flow Diagram
Once you know what you're producing, you need to provide some guidance as to what order it should be produced in. Some tasks may be able to be scheduled in parallel and others will require a precedent. By composing a product flow diagram you'll be able to picture this in a simple diagrammatic way.
* All diagrams are excerpts from the manual, Managing Successful Projects with PRINCE2.
Methodology vs framework – why waterfall and agile are not methodologies
There are often fights amongst people in the IT profession about whether the 'waterfall methodology' will or won't work. Over coffee friends and colleagues discuss why the 'agile methodology' is better, or alternatively, too hard to implement. It's also common for selection criteria to frame questions such as these (taken from real selection criteria and job descriptions):
"Experience in or an ability to acquire knowledge of software development methodologies (such as Agile development, Model Driven Architecture, etc.)."
"Application of a recognized software methodology (e.g. UML) to the design and development of embedded systems…"
It is shocking that intelligent, well educated people don't know the difference between a framework and a methodology. It's also shocking that prominent and respected organisations display this same ignorance. Who cares? Is this a semantic argument? No, this isn't a semantic argument and the difference between the two is an important distinction. It's important because a framework allows you to be loose and flexible; to have 'poetic license'. A methodology is much more prescriptive. Both can be handy at different times. But a methodology, is generally better and I'll show you why.
Definition of framework The Federal Enterprise Architecture Framework defines a framework as:
Generally within the software lifecycle realm, a framework is a picture or a model that guides you to understand which artefacts you should produce when. It doesn't tell you what to do though. For example, typically the waterfall framework begins with analysis as the first stage of software development. But it doesn't tell you how to do that analysis. Even if the framework is detailed enough to specify the template you should use, it won't tell you how to populate the template. Often though, a framework won't go into that much detail, giving you lots of flexibility to choose how you're going to do that stage. Flexibility is a guise though. Ambiguity is another term for it. You aren't compelled and guided to produce specific artefacts according to a process. Instead you are left to fumble your way through, trying to apply some kind of structure. This means that you will inevitably make different choices from your colleagues who are using the same framework. If your organisation only has a framework to guide its employees, there will be a lack of consistency. The problem is compounded when people think they have a methodology and all they have is a framework. As you can see in the quotes above, they employ people based on the wrong premise and they also loose faith that a methodology will guide them. They also start to argue about one framework being better than another, when what they are desperately seeking is a methodology.
SPEM does this by defining two things: method content and method process. Method content is what you do. Method content defines the artefacts that through a flexible method process are applicable in a number of different contexts. The method process shows you how to apply the same content for greens field development verses what you do when you are performing maintenance. The diagram below, directly out of the SPEM Specification, shows you concrete examples of how the two are combined.
Definition of framework The Federal Enterprise Architecture Framework defines a framework as:
"A logical structure for classifying and organizing complex information."
Generally within the software lifecycle realm, a framework is a picture or a model that guides you to understand which artefacts you should produce when. It doesn't tell you what to do though. For example, typically the waterfall framework begins with analysis as the first stage of software development. But it doesn't tell you how to do that analysis. Even if the framework is detailed enough to specify the template you should use, it won't tell you how to populate the template. Often though, a framework won't go into that much detail, giving you lots of flexibility to choose how you're going to do that stage. Flexibility is a guise though. Ambiguity is another term for it. You aren't compelled and guided to produce specific artefacts according to a process. Instead you are left to fumble your way through, trying to apply some kind of structure. This means that you will inevitably make different choices from your colleagues who are using the same framework. If your organisation only has a framework to guide its employees, there will be a lack of consistency. The problem is compounded when people think they have a methodology and all they have is a framework. As you can see in the quotes above, they employ people based on the wrong premise and they also loose faith that a methodology will guide them. They also start to argue about one framework being better than another, when what they are desperately seeking is a methodology.
Definition of methodology
"A documented approach for performing activities in a coherent, consistent, accountable, and repeatable manner."
The Object Management Group, the organisation that has carriage of the framework, UML, also has carriage of a standard that defines what people should expect from a methodology. The Software & Systems Process Engineering Meta-Model (SPEM) Specification is built to help people define methodologies.
The scope of SPEM is purposely limited to the minimal elements necessary to define any software and systems development process, without
adding specific features for particular development domains or disciplines (e.g., project management). The goal is to
accommodate a large range of development methods and processes of different styles, cultural backgrounds, levels of
formalism, lifecycle models, and communities.
SPEM does this by defining two things: method content and method process. Method content is what you do. Method content defines the artefacts that through a flexible method process are applicable in a number of different contexts. The method process shows you how to apply the same content for greens field development verses what you do when you are performing maintenance. The diagram below, directly out of the SPEM Specification, shows you concrete examples of how the two are combined.
Rational Unified Process (RUP) is one of the more popular methodologies. The SPEM specification illustrates how it displays both method content and method process.
A good methodology is adaptable to the situation and takes you clearly through the steps to produce quality, consistent artefacts. So if you're going to argue with your colleagues in the break out area, make sure you're both on the same page as to which one you're talking about. Because it's obvious you're arguing about more than just semantics.
