31 March 2009

Waste in requirements

This picture is from the ever-useful Standish report (aka Chaos report.)

It indicates how many deliverred features were used - ranging from always to never.

How many of the requirements in your specification/backlog are going to contribute to the orange or red sectors?  And how do useless (?) requirements get into systems when the same report tells us that many important features are never implemented?

A question for the experienced guys and gals reading this site - do you have some tips on how to manage this problem?

30 March 2009

Enterprise Architecture preview (BABOK 2.0)

Kevin has shared the beginnings of the IIBA's BABOK 2.0 chapter on Enterprise Architecture with us all on his website. We'll be digesting it in the next few days.

In the meantime there is an online launch of the new BABOK and you are invited.  It's tomorrow so check out the details now.

The wall of deliverables

There is something interesting happening at a website called The Wall of Deliverables.

The headline blurb from the website;  

"Welcome to the wallofdeliverables.com, a companion site for the IA Summit Wall of Deliverables annual event and an ongoing repository of deliverables submitted from the community to share. Take a look around, be inspired, and let us know what else you’d like to see!"

At the website you'll see a number of innovative ways of presenting business/software requirements.

There are a few intersting things there already, but you could probably help out by adding some of your creative and brilliant work.

(Found care of Catelyze)

28 March 2009

Did you know?

Many of these "facts" have been floating around in similar formats for a while. True or spin - this makes a nice story.

Thanks Ellen.

26 March 2009

BABOK 2.0 notes

Kevin from the IIBA has published this informatio on the new BABOK (version 2.)

25 March 2009

Is Enterprise Analysis really portfolio management?

Version 2 of the BABOK is coming out soon, so the IIBA's position on this might be changing, but upon inspection of the BABOK v 1.6 you get the feeling Enterprise Analysis is coverring the same ground as the project management community's concept of project portfolio management.

Let's take a closer look at the two concepts, and then in the not too distant future follow up with some commentary.

The BABOK's summary descripion says;
This knowledge area is the collection of pre-project or early project activities and approaches for capturing the necessary view of the business to provide context to requirements and functional design work for a given initiative and/or for long term planning. In some organizations this work is treated as an investigative, feasibility or business architecture initiative and treated as a project in itself.
This description is followed by a list of activities that may be used to support the process.
  • Creating and maintaining the Business Architecture
  • Conducting feasibility studies to determine the optimum business solution
  • Identifying new business opportunities
  • Scoping and defining the new business opportunity
  • Preparing the Business Case
  • Conducting the initial Risk Assessment
  • Preparing the Decision Package.
Conceptually this model is looking at a 'high level' requirements analysis process aimed at the organisation. Then, rather than features deliverred in software, or new processes designed and implementyed, the outcome of the analysis process is one or several projects.

This analysis process can generate significant information and so can aso inform how you initiate and plan projects.

The framework seems fair enough. I have done this myself and have seen other BAs work on this process also. When you come right down to the idea of business analysis it is about analysing the current situation, identifying problems/opportunities and their potential worth, and then assessing where to best spend the money.

You can do this in the context of a project, programme or at an organisational, or even industry level (hence the 'other BA community' of financial analysts.)

This work can be quite technical, but often also involves advanced consulting skills, as part of the process involves getting executivs to align their views and agree on a project investment startegy.

Some of the tools I have used to support me in the EA process include the balanced scorecard, strategy map, business model analysis, process modelling (at the higher levels), customer interviews and workshopping with execs.

The purpose of this post is to just put together a snapshot on the topic in preparation for a later discussion so I'll wrap up now with a request to the IIBA team to offer comment or clarification on my take.

24 March 2009

Marketing 101

When I studied marketing two decades ago, my first textbook was by Phillip Kotler.  His most recent revision of that textbook has been converted into a slide pack, and is hosted at Slideshare.

I think the best way to work through this slidepack is with a friend.  Grab someone you work with and set aside an hour or two to go through it and discuss the ideas raised in it.  How do they apply to your project?

This pack goes through Kotlers ideas chapter by chapter and end with some discussion questions, so it is easily broken down into several sittings.

Have fun, and let me know what you think.

23 March 2009

BA Taxonomies

Alex Papworth at BusniessAnalystMentor.com has created a list of BA categories.

The categories include labels like Journeyman, Domain specialist, technical specialist and otehrs. Alex has a pretty good blog with lots of good BA articles. Go check it out starting with the BA categories post.

It got me thinking about the topic (not for the first time) and so I threw together this model.

Do you have a mental model of BA types? If so, how about another meme?

Write up your thoughts and link back to Alex's blog post (and maybe here) and we'll compare.


20 March 2009

Imagine being in Shakepere's English class

This is a discussion on the topic of education. It is amusing and pertinent.

And there is a message in there for you about how to manage your continuing education.

(Thanks Jurgen for pointing me at this.)

19 March 2009

A downside of agile development?

I use a few online services, and you can tell which ones have adopted the philosopy of incremental product roll-out.

Just about every time you log in, there is another feature being promoted and presented to you for consideration.  Sometimes things you were used to have moved or disappeared.

This constant change makes some products less appealing than something that is more reliable.

Yes, it''s the internet age and kids these days are disappointed they have to wait four hours until a new feature is released, but I think many of us still like the tools we use to have some semblance of stability.

Large enterprises aren't known for their restraint when it comes to change.  Frontline workers are used to constant process tweaking and product modifications.  (Think mobile phone and internet plans.)

I remember managing a team which was the communications focal point for all system, process and product changes for a particular organisation.  At the end of my first year we looked back at how much change had been funnelled through our team and discoverred it was about 3000 initiatives.  That added up to about one change initiative per staff member in a year!

At another job I talked about our project change management plan in the context of an organisation that had just gone through a series of large and significant changes.  The staff were suffering from 'change fatigue.'

Will an agile development approach amplify this problem?

As project people, how do we balance the benefit to us of frequent small delivery against the cost to our clients and users of dealing with too much change?

Have you got experience dealing with this dilemma?  What did you do and how did it work out?

Happy St Patrick's day - I'm having  guiness to celebrate :)

18 March 2009

Requirements management as Agency

The blog post "Where have all the agents gone" by Seth Godin prompted recurring questions for me;

How is it that there are requirements managers still out there when all they do is transport requirments from users/stakeholders to the development team?

What value do these peple add beyond saving you the pain of filling in corporate templates?

How should a business analyst (or product owner or customer advocate) contribute to the reqirements management process?

Where is the value you are adding?

Picture by timlewisnm CC @ Flickr

17 March 2009

The spurious bullshit that goes into busness cases

Dave said it;
All these efficiency projects never result in less staff.  Why doesn't someone 'fess up and dmit these projects are so that we can afford to go out and buy things from this and similar corporations?

It's a cynical line, and among all the pessimism out there today about career prospects there is also some optimism that finally project sponsors and going to sit up and pay attention to what is happening on their projects. Well... maybe.

Let me ask you this; how closely does your project's goal align with the goals articulated in your business case?

Does your business case say that the new fangled IT system is going to bring in cost savings or revenues?

How are those revenues derived?  From serious market research?  From historical trends?  From competitor analysis?  A pilot?

And what about the efficiency savings?  I remember another conversation from years ago with someone who had just reviewed the last 2 years worth of business cases across the organisation.  If we had made good on our goals we would have negative staff numbers.

Obviously this is mainly just a rant, but there are also some practical actions you can take to manage these over-promises.

One is draw a diagram showing how the benefits will be realised and how they will flow into the organisation.  Tag all the assumptions and challenge the business cases' author on them.

Another is to provide a capability statement of your end product, rather than say how much money it will make or save.  Clearly delimit the task of building that capability from realising the benefits, which will fall to a senior manager in the operations world.

A third option is to adopt an iterative/incremental build up of a solution.  Then you can make smaller guesses and watch as the benefits are realised and correct as neccessary.

Picture by Daniel Gasienica CC @ Flickr

15 March 2009

Identify Project Stakeholders, a first step in requirements management

I finally got a bit of a stakeolder analysis done for my project today. Questions it helps answer...
  • What groups within the organisation will use the system? 
  • Who is representing thier needs to my project team?  
  • Will there be any orgotten requirements?  
  • How will we release features to them? 
  • How will we manage the change that comes with new tools?
Not to mention the usual stakeholder analysis benefits!

Alistair Cockburn writes:

"One consultant described the first time he and his group listed the stakeholders and their interests for a system they had recently shipped. They suddenly found themselves looking at most of the change requests that had been generated in the first year of operation! In other words, had they simply written down the stakeholders and interests for each use case early on, they would have avoided an entire category of mistakes that didn’t show up until after they had delivered their system. Other people have reported similar experiences. Several people say they find value in listing the stakeholders and interests however casually and informally their capture requirements."

Photo by ewanr CC @ Flickr

14 March 2009

Fear and loathing

I found this post in my drafts form about a year ago. A similar theme to one I posted last month. It appears to be a recurring theme! Anyway, here is what I was thinking a year ago.

The other day I was thinking about how marketers use fear to make people buy things. It’s a really simple and easy way to get people motivated. (See John Kotter’s model on change management for a perspective on this.)

Fear really does seem to motivate people more than positive sentiments. Which of the following sentences has the more powerful message?

Smoke and die a horrible death.
Quite smoking and enjoy a healthy body longer.

This reflection led me to think about how people are motivated at work.

There is an aspiration for workers to come in and be intrinsically motivated by the work. And there is also a worldview that work is something we have to put up with in order to get the things we want (money, prestige, power, etc.)

This is the essence of the Theory X and Y on management by Douglas McGregor.

Organisational and behavioural theory has moved on, and we are encouraged to be a lot more situational and holistic these days.

We are treated (cursed?) with particularly interesting jobs and so something called Theory Z applies to us.

Theory Z is a model that says “If the organisation can make the work interesting and fulfilling our workers will enjoy it more and thus be more loyal to the company.

There are a few caveats to this model for you and me.
As people who go from project to project our loyalty is more likely to be to the project team than to the organisation, but not always. It depends on our relationship with our employer. And the degree to which we are satisfied and challenged will not be binary and it will change over time.
Anyway, two points on this topic.

1. Project team members seem to almost never quit midway through a project. Why is this? Are we really that motivated? I expect so, as our jobs really are challenging, interesting and rewarding (Sometimes.)
2. So many other people seem to be motivated by maintaining the status quo, so they can keep their jobs safe, hold the power and authority they have gradually built up, not have to deal with change (=risk.)

What’s up with that?

Maybe management should project-ize everything so the staff can be really engaged with the work.

13 March 2009

Agile survey

I ran a survey on this site asking whether you had heard of/engaged with/ignored the agile thing going on out there. Here is what 62 of you told me;

Got it 26 (42%)
Get it 18 (29%)
Don't get it 10 (16%)
Not even paying attention 8 (13%)

What does this suggest to me?

Naturally there is going to b a strong awareness of agile methods among blog readers. If you are here you are actively seking out new knowledge. You couldn't miss the noise.

This explains the 71% of you who "got it' or 'get it.' Presumably "Got it' measn you are or have used some sort of agile methods on your projects, and 'Get it' measn you are read up and (agree or not) feel you understand the principles and processes.

The 29% of you who 'don't get it' or 'aren't payng attention' - I have some guesses about this, but I'd love it of you drop in a comment or two to elaborate.

Firstly - some of you are possibly new to projects and to the online projects community. And maybe some of you are from physical engineering or construction backgrounds. (Anyone?)

Secondly - some of you are old hands and just see it as another method or fad which is just another formalisation of 'not doing stupid things on purpose.'

Thirdly - some of you might be coming from markets where the agile methods have not made any inroads yet. (Japan? Korea? I have no idea what's happening there in the projects community.)

Lastly - there will be a few of you who are just tired of the noise and want to forget it and get on with things.

So, I am curious. If you are one of these later categories - would you mind offerring a comment to let me kow if I guessed right? And if not, what the real reasons are for you answer?

Picture by Giant Ginkgo CC @ Flickr

11 March 2009

Posting frequency @ betterprojects.net

Hi readers,

I am runing a survey asking what you think would be the best posting frequency at this blog.  Your answers will be useful to me : )

It used to be the Iron Triangle

The iron triangle of time cost and scope has been updated to the project diamond.

A while ago I was advised to not only bcome familiar with the concepts in the iron triangle (now diamond), but to take them to the project sponsor and key stakeholders and get the dimensions ranked.

The benefit of doing this is twofold;

1. You quickly reveal the misalignment in stakeholer and sponsor priorities.
2. Your team can then get on and make decisions on scope, quality and schedule without having to refer back to the sterring committee so often.

Ranking priorities highlights the issue that money matters to the peson paying (i.e. the sponsor), but not to frontline managers or SMEs who work with your team day to day on articulating requirements.  This may be one of the sources for enterprise project over-runs and scope creep.

By clearly and publicly setting the priorities it gets easier to manage people's expectations abut what can and should be one by the project team.

Take a look at how I think my current project diamond dimensions are ranked by the sponsor.This set of priorities does not line up with the key stakehodlers, but here it is out in public and it becomes a much more managable issue.

10 March 2009

Iterations and the value payoff

A simple presentation on the increased value you get fron iteative approaches to software development.

This is not a deep, evidence based moel - it's more a simple principle based view of how value is earned faster. (It's part of the agile dogma, in fact.)

It's posted here because it's a potentially useful communicatio tool when arguing for iterative development.

9 March 2009

A management context for sucessful projects

I read/skimmed a thesis investigating project methods by Diane Strode. In her findings she articulates a list of important evironmental-managerial factors. Diane identifies a correlation with adoption of agile methods. They also look like they correlate with generally positive outcomes over bureacracy and failures.
  1. The organisation values feedback and learning. Social interaction in the organisation is trustful, collaborative, and competent
  2. The organisation values teamwork, is flexible and participative, and encourages social interaction. The project manager acts as a facilitator
  3. The organisation enables empowerment of people
  4. The management style is that of leadership and collaboration
  5. The organisation is results oriented
  6. Leadership in the organisation is entrepreneurial, innovative, and risk taking
  7. The organisation is based on loyalty and mutual trust and commitment
  8. Projects undergoing constant change
Can any substantial corporate project succeed without these factors being present?
  • The thesis is here.
  • A powerpoint summary is below.
The picture at th top is by Thunderchild tm CC @ Flickr.

8 March 2009

On PMP Certifications

Raven asks why we have or haven't got a PMP certification.

I don't have it.

I do have a masters degree in project management.  I have a reasonably good work history with the ability to provide good references.  I lecture part time on project management at a university.  And of course there is this blog, which is basically my learning journal on the topic.

I figure that my personal network and paper history will put me in the front of the pack for most jobs I apply for, but right now I am not in the market so not thinking about it (until now.)

I can talk and manage my way though the PMP, and as you'll note from reading this blog, my thoughts extend way beyond the PMBOK so I can handle a curveball or two also.  I know the content and I don't see doing the test is going to help me learn much.  But that's because I did the masters degree.

I may get the PMP for the resume eventually.

I recently sat the certified scrum master training, mainly because I wanted the formal structured learning to make sure I had all the bits and peices evenly understood.  I also recognise it will help me in my future job hunting.

So, if you haven't had advanced training - I'd recommend it.  I would definitely put a university course ahead of a 3 hour multiple choice questionnaire, but if that's what you can afford, and it gets quick results, why not?
Photo by me

7 March 2009

The difference between Use Cases and User Stories

I just watched an interview by Alistair Cockburn on InfoQ. Towards the end he talks about the difference between user stories and use cases. (You can skip to the specific question if you don't want to hear the whole thing.)

Among some of the unique user story features he notes are;
  • The ability to keep splitting user stories to fit them into sprints
  • The ability to address usability issues better
  • User stories are attached to value statements that help prioritise them
  • User stories help you identify the shortest path to a complete or releasable product
The other day I was listening to a discussion on the topic and it struck me there is another difference;
  • User stories are centered around the user
  • Use cases are centered around the system
Check out the wikipedia pages
And lastly have a read of this article by Scott Sehlhorst on the two types of requirements articulation: User Stories and Use Cases.

Picture by jakuza CC at Flickr.

5 March 2009

Ben Warsop's BA Blog

Care of the meme I put out the other day I discoverred a realy great BA blog I want to share with you. And to whet your appetite I'll share this nifty diagram demonstrating a fresh take of the six fundmental BA questions.

Go to the blog to read the logic behind the structure and for a bigger picture or better yet go read the whole thing. There's plenty of sharp insight and useful knowledge there.

I've got her blog in my RSS feeds right now and will be paying more attention from now on.

1 March 2009

Getting through to executives

ln response to a conversation about sponsors and execs Pawel's blog I discoverred this gem.

Worth a look before you start on your next steering committee pack.