27 February 2009

A meme on modelling

I propose a meme for our BA and PM bloggers.

Recall the first and last analysis model you used at work.

The first model I can recall using was a SWOT analysis back in my first year at Optus in a business process improvement team. I can't really remember the details but I'm pretty sure it had something to do with PayTV billing cycles.

The last model I used was an affinity diagram where I linked business case goals to a requiements spec's top level feature set (which was derived using a product breakdown/functional decompostion.)

(I've plugged in the wikipedia links to descriptions of each of these models.)

I'm keen to see what you guys put up - what models are we using and how?

Julian/Kevin, Jonathan, Maria, Pawel, Andrew, Bas, Raven and Scott - tell me your answers & pass it on.

And anyone esle? Josh, Glen, Rick...

Dont forget to link back to this post so I can track the replies.

(Photo by Simon Pais-Thomas CC @ Flickr.)

24 February 2009

Agile or Plan Driven?

A couple of years ago software development luminary Barry Boehm teamed up with project management guru Richard Turner and write a book called "Balancing Agility and Discipline" which explored the plan driven and agile process debate.

Among the gems in the book they present a model for determining whether you should run your project as plan driven or agile. Here's a personal example for one of my projects.

It's simplified for the pupose of this blog post, but you'll see there are five dimensions by which you are encouraged to assess your project. How big and risky is the project? What are your capabilities?

Depending on the answers to these questions you end up in one home territory or another. In some instances you fall into an 'in-between' state. In which case you are encouraged to start with the home ground bias you have identified and modify the process to suit the circumstances.

Personal - Team member capability
  • Very high capability > high capability > Average capability > Below average capability >Low capability

Criticality - Loss due to defects
  • Comfort > Discrtetionary funds > Essential funds > Single life > Multiple lives

Size - # of people on team
  • 2 > 3  > 10  > 30  > 100  > 300
Culture - bias to chaos v order
  • 90%  > 70%  > 50%  > 30%  > 10% 
Dynamism - % change in req's per month
  • 50%  > 30%  > 10%  > 5%  > 1%
How is does your current project map to this profile?

22 February 2009

20 February 2009

Schwaber on Scrum

This clip is an hour long but worth watching.

Some of the concepts he talks about have since been elaborated to handle questions about enterprise complexity.

If you are unfamilar with the details of Scrum this is a good intro discussion. If you are a user and haven't seen this clip it can deepen your knowledge and help you implement it better.

19 February 2009

You think you've got problems?

Nick Malik writes a fantastic blog on Enterprise Architecture. He even generously provided me with a post a while back.

This week he's provided another excellent  post and on a topic that's close to your heart; Understanding the root causes of poor software requirements.

He's Ishikawa'd (?) his way to 149 root causes of poor requirements.

Off you go. Read it now.

This -> 
is the only 
photo I could find 
of Nick online :)

Hardhat photo Rob Shenk by CC @ Flickr

18 February 2009

Political Analysts

Jon Babcock asks the question - Can you apply BA skills and methods to government policy and legislation? Will it get better value for taxpayer dollar?

It's something I've thought about before and my answer is a definite yes.

What do you think?

17 February 2009

Business cases

A business case is a case for doing something.

“Here is my case for change!”

That something could be to either ‘run a project’ or ‘build a product’ or ‘improve a process’ or ‘renegotiate a contract.’ It could be other things also.

Business cases do two things;
  • Describe an exploration of the costs and benefits of doing something, and
  • Explain how you’ll measure when or whether you are ‘done’ at the end
The key attributes of this description are;
  • Describe
  • Doing something
  • Costs
  • Benefits
  • Measuring
  • When you are done
(If you go to your corporate intranet right now and look up the business case template that is provided I wonder if the template focuses you in on these fundamental areas?)

Here is what I think you need to focus on to build up a business case. Regardless of what your template drives you towards, these are the things I think you need to focus on.
  • What is the problem or opportunity you are addressing?
  • What’s your vision for the solution?
    • Check this vision off against the SMART objectives criteria – Specific, Measureable, Achievable, Relevant, Time based
    • Are there multiple parts to your solution? If so, break them down (via a WBS or PBS) and set SMART goals for each solution component
  • How capable are you of getting to these solutions?
    • What are the costs? Effort & duration estimates – analogous at first, then more refined, Capital, Cost of organisational inefficiencies
    • What are the risks? Cost your risk in terms of money and time
    • What are the environmental constraints?
  • What benefits will your organisation get from doing this?
    • Use the balanced scorecard or a similar model to help ensure coverage of all key benefits areas. (Financial, customer/stakeholder, process control/quality and building in flexibility for the future)
  • How will you measure your benefits? What is the baseline you are measuring against? How will you isolate this project’s benefits from other initiatives and environmental changes?
  • How will you know when you project or product is complete?
    • Completion criteria can be defined up-front
    • Where agreement on completion criteria cannot be obtained, focus on a process to help define ‘done.’
If you address these things, will your business case do what it needs to do?

Photo by Pikturewerk CC @ Flickr

13 February 2009

Elevator pitching your release

These days we want to bundle requirements into releases. (Large proejcts are highly risky and breaking things down reduces some of this risk.)

As the requirements manager you are the one who has the vision for what will be in - and out - of the release.

It's a useful excercise to be able to wrap up your release into an elevator pitch. It helps you focus.

And face it. If you were seeking VC money, you'd have to be able to render your complicated vision down to a few snappy phrases.

Here's a website to help you think through or elevator pitch.  (And here is the inspiration for this post.)

How to review business requirements (for project stakeholders)

Hi readers,

This is an early draft. Feedback would be appreciated.


12 February 2009

Confusion over team role

Projects come in different sizes and shapes. And your project team can also be quite different depending on the nature of the project.

Today I was in a meeting where I realised some of us were working with one mental model of the project team’s role while others were working with a different one.

The divide seemed to lay in the idea of the whether performing team is a service provider to, or a change agent within the client organisation.

What do I mean by this? Let me run through some working definitions of the key terms here. These definitions are nothing too formal.

Performing team
The performing team is a concept of the performing organisation. It’s lifted out of the PMBOK. The performing organisation is the organisation that is going to carry out the actual work of the project.

In some projects the performing organisation is a team wholly within the client organisation. It may also be several cross-functional teams coming together in a tightly or loosely linked association under the banner of one project or programme.

In some projects the performing organisation is wholly external to the client organisation. A fully outsourced solution is an example of this. In projects like this the client has put the project fully in the hands of their provider. This is unusual for large enterprise projects as there are so many inter-related parts, however it is not so unusual in small discreet system or facilities projects.

A third scenario is where the performing organisation is a mix of members from external partners and people native to the client organisation. In this instance you may have some or all of the IT build outsourced, but much of the project, requirements and change management work is based within the client organisation.

Service provider
A service provider is someone or an organisation that is external to the client organisation and provides a service – such as building software, managing projects or whatever other needs you are unable or don’t want to provide internally.

Service providers are usually hired on a contract that specifies the services they are to provide. As most project’s don’t know all the work to be done up-front service providers use a balance of doing a bit extra for goodwill and being disciplined about change controls to manage variations from the contract and most importantly: what they get paid.

So a service provider is hired for a specific purpose. At the end of the delivery period you should e able to look back and say “Did we get what we paid for?” And service providers should be able to look back and say “Did we do what we said we would?”

Missing from this conversation is “Did the client get what they wanted?” as that issue is mostly left for the client to manage internally.

Change agent
Change agents are people who work with the client. They can be internal staff or external people, and are often consultants. Their goal is on enabling the client to transform from their current state to their target state.

Their measure of success is around the achievement of the goals.

Client organisation
The client organisation is the organisation the project is being run for. In the case of enterprise projects it is the enterprise itself, and any times can be defined a business unit within a larger enterprise.

The client organisation is the one paying the bills, and (usually) collecting the benefits.

So where is the confusion coming from?
When you are an external performing organisation you deliver what is required in the contract, including planning documents, milestone deliverables and so on.

If you hand over a technical design document to the client and they have no-one available to read through the techno-speak that’s the client’s problem. They can either pay you to explain it to them , or go find someone else to do the same thing.

However, when you are part of the client organisation you are committed to overall project success, not just delivery per the contract.

In this case it’s up to you to help manage the client and key stakeholders through a process. Hard to read technical documentation is now your problem, not theirs alone.

And so we come to the need for a different mindset when you are working within the client compared to when you work as a services vendor.

In this instance your documentation focus needs to change from technical specifications and contractual terms to one of clear and effective communication and enabling change.

In this world it is much more important to produce project documentation that includes things like
  • Problem/Opportunity statements
  • Project vision
  • Guiding principles
  • Change strategy
  • Success and Failure criteria

The more traditional approach of “Scope > Requirements > Solution Design“ becomes a secondary in importance. If you put them first you run the likely risk of leaving your stakeholders behind.

10 February 2009

Step Back from Chaos

Imagine a world with no project managers.

Can't do it?  watch/listen to thi presentation by Jon Whitty; "Step Back from Chaos"

(Thanks for the pointer Bas.)

There are 2 things I puled out of this;
  1. As a project manager you job really isn't to try to control what's going on, and
  2. When you have complex and challenging stakeholders there are potential tools to help you identify and manage trouble spots before they erupt.

Image care of Andrew Coulter Enright CC @ Flickr

8 February 2009

Customer Segmentation Principles

As you know, I think an understanding of your customer is a key succes factor for a project professional.  And that applies to both your project sponsor and main stakeholders on the "project as an organisation" dimension, and to the real "end user" or beneficary of your project's outcome.

Something we always find challenging, for example, is how much is enough?  At what point do the requirements or features stop being meaningful? If you have applied Kano analysis to your requirements how do you understand which features are going to delight your customers, and which are merely mundane mandatory features?

To be able to get to this level of understanding you'll need to understand your product's customer segements and what matters to them. Start the proces by breaking down your customers into various segments.

Here are some tips;

6 February 2009

Fear and panic

After thinking about how project workers seem to be pretty engaged with their work and many operations people are more interested in maintaining the status quo I got to thinking about the way we approach change management.

A lot of the corporate change programmes I have seen (and been a part of) have involved educating the affected people about the ease of the change, the benefits to them and the organisation.

“By adopting this new business process/IT system/reporting framework you’ll be able to save money and get more done!”

And people just don’t care. They snap back to their previous practices like a tightly wound rubber band.

What would happen if we used fear as a motivator? It seems to me that many of the leading change management practitioners actually do that. Especially with senior management.

Can we apply it to frontline users and project stakeholders?

“If we don’t enable ourselves with this internet thing we’ll be out of business by October next year!”

Are there any change practitioners out there using fear to get change to happen?

Does it work?

Photo by Bah Humbug and CC @ flickr

5 February 2009

The concept of Ba

BA's, you may be intereted in something called "Ba."

"According to the theory of existentialism, Ba is a context, which harbours meaning. Thus, ba can be considered as a shared space that serves as a foundation for knowledge creation." (Source)

Here is a blog post with further information and links.  You may find it interesting.  I'd like to hear your thoughts on the topic.

  • "The concept of Ba"