POTI: A Model for Programme Blueprints

The OGC’s Managing Successful Programmes (MSP) framework uses a categorisation process to identify areas of scope that should be considered by the programme Blueprint.

A Blueprint is a detailed vision for the organisation, covering what the organisation will look like when all the projects are completed, the programme is wound up, and the business transformation is done.  Typically, you would only write a Blueprint at programme level, so project managers will ‘inherit’ a Blueprint from their programme manager.  If you are leading a project as part of a bigger initiative being managed as a programme, ask to see the Blueprint if you haven’t already.  It will help set your project in the wider context of what the business is trying to achieve.

In particular, Blueprints use the POTI model as a way to define the scope of what is going to change once all the projects in the programme are complete.  POTI sets out the scope of the programme at a high level.

POTI stands for Processes, Organisation, Technology and Information.  These four areas make up a comprehensive view of all the elements that form the programme scope.

Read more »

Doing the Right Things for Your Customer

Customers are a demanding group … that’s a given. When we have all of our regular project responsibilities to deal with on a daily and weekly basis, how do we know when we’re doing the right things for our customers? How do we know we’re managing them well, responding to the right requests, saying ‘yes’ when we should and saying ‘no’ when we should, and ensuring that our actions are not detrimental to the forward progress of our project?

You can’t always base it on customer satisfaction levels. Because attentive ‘do-anything-for-the-customer’ behavior may get a project manager and team high marks mid-way through a project. But upon implementation, if they’ve said yes to too many things that ended up modifying scope and delivering a system to the customer that is ultimately not what they ordered, then that customer satisfaction at the end of the project will be low. The end user community will have a product that they didn’t sign up for and that’s a very bad thing.

In order to ensure we’re doing right by our customers, we first need to have confidence in what we’re doing. And we need to have confidence that we’re doing the right things for the project. We can do that in a few ways, including:

Read more »

Improving Requirements Quality with Use Cases

People sometimes like to dive right in to requirements definition by simply starting to write them on a blank sheet of paper – or blank Word doc for those of us who have gone completely green. Starting the requirements definition process this way can be very intimidating at best and full of oversights, omissions, and conflicts at worst. Even if you define and document scope in detail as I’ve discussed in the past, it’s still a big leap from a scope document to detailed requirements. Customers often have a hard time with requirements and you certainly can’t write all the requirements for them. You can help … but be sure to bill for it.

Sample ATM system usage use case diagram

Use cases are a simple, cost-effective way to build a consensus among stakeholders and to discover missing requirements. They tend to address two large classes of requirements errors – omitted requirements and conflicting requirements. While drilling down further into requirements, the customer – usually with your help – can utilize use cases to get detailed requirements across all life-cycle phases to support the requirements definition process.

Why develop use cases?

Use cases are relatively easy to generate. The customer must access their stakeholders and subject matter experts (SMEs) to get well-thought out use cases that can be used to derive detailed and meaningful requirements for the engagement. Below are some of the reasons and pluses for generating these use cases: Read more »

Scoping the Project for Better Requirements

Good scope before requirements

The earlier you define scope, the more efficient your requirement definition process will be. Work done before scope definition is usually wasted effort. An early scope definition keeps requirements writers from diverging, reduces requirement inconsistencies, and keeps the big picture in view. It also shortens the time required for requirement writing and rewriting and reduces debates.

If you do not give everyone writing or reviewing requirements your scope definition, they are likely to create their own. Imagine listening to a movie without watching it – as I have done many times on trips in the SUV listening to a movie several times but never seeing it as it’s playing in the DVD player behind my head. I have a vision – my own vision – of what’s going on and what the characters look like and what the set looks like, but if no one describes it to me in detail or I don’t see it for myself then that’s all it is … my own vision. And it likely differs greatly from the actual film itself. Read more »

How Much Effort Should Scope Definition Take?

The post is made possible by the great people at Seavus, creators of online Project Management tools such as ProjectOffice.net, Project Viewer, and Project Planner.  Please visit their site for more information.

We’ve looked at how you go about communicating scope, now let’s look at the concept of how much effort should go into defining the scope of your project or product development process. This article is based somewhat on text from the book “Customer-Centered Products” by Hooks and Farry.

Scope definition is one of the most critical aspects of project or product management. Without proper scope definition, a project is destined to experience continual scope creep resulting in ongoing timeline and budgeting issues.

When the scope creep happens, the only way around the timeline and budgeting issues will be to introduce many change orders to your customer which will likely decrease their satisfaction level significantly. You’ll still have the timeline issues and the budget issues, but you’ll be able to justify them with the stack of change orders – assuming the customer actually approves all of them rather than flat out canceling the project altogether out of frustration. A much better route is to spend the proper amount of time up front correctly identifying and documenting scope and gaining agreement with the customer on that carefully defined scope. Read more »