30 September 2009

As a project manager

As a project manager my job involves two main responsibilities;
  1. Providing an environment condusive for the team to do their best work
  2. Keep the client informed about progress, specifically addressing expected budget schedule and scope.
As a project team member - or customer - does anything else stand out as important?

Pic by Photomish Dan, CC at Flickr

29 September 2009

Another BA Competency framework

Carrying on from Ambler’s essay on Agile Business Analysts; I want to throw up Scott’s list of “Do’s and Don’ts” for business analysts as a potential for a competency framework.


There is a discussion going on at Linkedin (It's the Modern Analyst Group) about BA Competency frameworks and, well, heck, why not offer another point of view.


Take a look at the list of positive contributions and assess yourself or your BA team members on a scale of 1-5, then take a look at the negative contributions and score from 1-5 again.

This model is derived in part from Frederick Herzberg’s Hygene theory of management and Kano requirements analysis which acknowledge that there are both potential positive and negative outcomes of things such as management and features.

Positive contributions
  • Scope the system
  • Translate business needs
  • Translate technical issues
  • Model and document
  • Act as a communication broker
  • Political mentor
  • Test and validation
  • Represent stakeholders
Negative contributions
  • BAs often lack the right skills
  • BAs can have undue project influence
  • BAs can be out of date
  • BAs can act as a communication barrier
  • BAs can reduce stakeholder influence
  • BAs often over analyse
  • BAs can reduce feedback
  • BAs can reduce opportunities for developers to gain communication skills

Some of these terms need some filling in. An example; “BSAs often lack the right skills.” What are the right skills? What is their purpose? What is their context? What important outcomes will this lack of skills affect?

For Scott’s definition you can go to his article. You can also make up your own to suit your context. Remember that the context is the important think. For example, UML doesn’t matter as much as the ability to effectively get their product vision across to developers and stakeholders.

28 September 2009

Rethinking the role of a BA on Agile projects

Scott Ambler has a pretty solid library of tools and techniques on all sorts of agile practices. One particular essay he has written is on “Rethinking the role of the Business Analyst; Towards Agile Analysts?”
I read Scott’s basic view on the topic as two main points;
  • Analysis is critical to project success, analysts are not, and
  • The right degree of up front analysis is not none, but it is not as much as people expect
I buy both these propositions.

Scott has a third position;
  • The role of the BA is to overcome barriers such as competency and time
In his essay Scott calls the BA a “Band Aid” – highlighting the role as a patch for a more deeply ingrained problem.

I don’t buy that one. While he has some valid points, the BA in an enterprise also plays a legitimate & important role in balancing competing priorities. Scott will say that this is the role of a project sponsor, but in truth senior managers have to delegate.

A BA may – can – and in many cases – should - act as a product owner or sponsor/customer advocate. It’s a natural evolution of many Business Analysts roles.

This adoption of responsibility can be done with or without adopting agile processes and practices. It’s about taking responsibility for project/product outcomes and working with the team on achieving them.

27 September 2009

Information architects are like Robin Hood

"We may look like pansies..."

You can see more of this at the OZIA conference in Sydney Fridat and Saturday this week.

25 September 2009

Red Planet

On Wednesday this week Sydney woke up to a seriously odd weather event.  A massive dust storm had blown across the continent and this is what we got.

24 September 2009

Business Analyst as Product Owner, Canberra version

I spoke again at the Busniess Analyst Symposium in Canberra on Monday.  It was interesting being in the city and hearing the stories of governement project workers.  They have a very different story to the ones you hear in the private sector.  All respect due to people working in tough contexts.

Anyway - you have seen the initial draft of the presentation I did, plus the Prezi version.  Here, in my last talk for the year I went back to powerpoint.  I'll elaborate on why, and on my expereinces in a future post, but for now, maybe this will help someone somewhere think about the differences and similarities between the BA and PO.

23 September 2009

When you come to a fork in the road... Stop and think!

You have probably heard the original quote a million times.  This variation comes to you care of Chris Matts and Olav Maassen who wrote a piece in 2007 called Real Options, which about deferring decisions until the last responsible moment.  The article is applying the maths behind options trading and some phychology to decision making in software product management.
Instead of saying "not yet", the Real Option approach says "Make the decision when..."
There is some good common sense in this article, but you can see people forgetting the second word of the phrase "last responsible moment."

Also it's got to be hard for people to go from a pattern of planning as much as you can to planning as little as you can.  I can see master practioners pulling it off, but I can also see mayhem as people abandon plans rather than schedule decisions based on the theories and ideas that support the essay.

Head over, read the article - and read the comments which provide quite a few clarifications and elaborations.
Photo by Whatknot and cc via Flickr.

21 September 2009

Am I a Business Analyst?

I asked Paul Culmsee if he could go to the Perth BA World conference as a speaker.  I had read his blog and his posts on Wicked Problems and Dialogue Mapping grabbed me as interesting and important for the BA community to learn about. (Paul lives in Perth)

He's back from the speaking engagement and has written this provocative piece challenging the BA as a translator metaphor.  I have never liked it, as I see no substantial value in such a role, but I've never quite been able to articulate what was wrong with it.  Now, thanks to Paul, I can.

19 September 2009


People in the Sydney area, here are several intersting conferences coming up.  See the list below, and feel free to add any extras in the comments;

AWRE '09 - 2nd October
The 12th Australian Workshop Requirements Engineering is to be held on Friday the 2nd October.  This is a one day even, and includes a post wormk session at 7pm.  AWRE has been sponsored out of Sydney's University of Technology and will be at their Sydney CBD campus.  Details.

(I previewed the papers they are presenting for this session a few weeks ago, and most of the content looked very interesting.  It's a mix of academic research and practioner experiences.)

Australia's Information Architecture Conference is going to be held on Friday the 2nd and Satursday the 3rd of October.  The focus of this conference is on user experience, user interaction design etc.  There will be lots of 'colour' and creativity at this event.  And half of it is on a Saturday so you don't have to skip out of work.

(By the way - the IA people's website looks cooler than the other conferences presented here.)

Agile Australia '09
The Australian Agile conference will be at Sydney on the 12th and 13th of October.  The big themes appear to be implementing and scaling agile for the enterprise.  There is solid representation from some of Australia's largest corporates on the presentation roster, demonstraing that, as in North America and Europe, this agile thing has gone mainstream.  Details.

BA World, Canberra, Brisbane
Canberra is this Monday, so if that's your town get organised.  (I'll be there on Monday talking about how BAs can reinvent themselves for agile projects.)

The dates of the two reaining events are
  • Canberra - Sept 21-22
  • Brisbane - Oct 9-10
I have attended two of these sessions already (Sydney and Melbourne) and can attest that they are a fantastic event for business analysts of all shades.  They would probably be useful for project managers, tech leads and other 'project leaders' also.

Picture by Kid Paparazzi, CC @ Flickr

17 September 2009

Requirements taxonomy (again)

Last week I pointed you to a spirited discussion at the Requirements Engineering discussion group.  As the discussion went on Don Firesmith offerred to share a diagram showing the varous ways he classifies requirements.

A particular thing he wants you tonote is the lack of a category called "Non Functional."

Analysts - What are your thoughts?

16 September 2009

BA World Canberra

Will be there on Monday.

Design patterns for requirements

Last week I mentioned design patterns used by developers.  They were an outcome of some experienced practioners looking around and seeing the same problems being addressed over and over again in different contexts.

Naturally this principle can be applied to business requirements as well.  As an example take a look at your local bug tracking tool.  I bet it's got the same features as my bug tracking tool, and that other reader's tool as well.

Features will include the ability to enter a bug name and description, add a screenshot or other image, generate reports on inflow and clsure rates, mean time to close etc, and the ability to move bugs through a couple of states from new to closed.

Did the product managers for these tools all hve to go to clients and learn about their needs, run focus groups and gather feedback customer by customer?  Did they then have to go an write up (or otherwise explain) specific and detailed requirements for each requirement?

Well, yes and no.  Yes they did have to all indepedently articulate requirements for the dev team, but no - not all the requirements needed to be elicited from scratch. For example, a BA or product manager may have been recuited from a competitir, or may have several years as a project manager or project tester under their belt and can thus go straight to the heart of the issue from direct experience.

In these cases personal patterns are leveraged.

Take a moment to think about your experience and the degree to which you elicit requirements versus make them up from your own experience.  If you have any substantial experience you can't help apply your own judgement to how a reqirement should play.  You may be wrong - and the verification process will tell you that, but the shortcust that experience provides are invaluable.  (Thats why experience commands a $premium.)

Interesed in reading more? Check out Martin Fowler's website, or his books on analysis patterns.
Craig Larman is another person I read and he has a book too;

Picture by Penguin & Fish CC at Flickr

15 September 2009

Why Big Software Projects Fail: The 12 Key Questions, by Watts Humphrey

Watts Humphrey is the SEI's CMM for software guy, and now the TSP guy.

Many of us have have heard about CMM for Software (now replced by CMMi), but few of us know much about TSP or its cousin PSP.  I came across PSP and TSP when reading "Balancing Agility and Discipline; A guide for the perplexed" by Richard Turner and Barry Boehm, investigating the differerces in approach of Agile/XP and SEI approaches to project managament.

TSP (as I understand it) is a project model where the planning is separated into layers; with the top layers being the domain of management (e.g. what capabilities are deliverred in which order) and the doing work of the developer (and similar level) team is by the people who do the work. 

Maybe it's the crossroads of the engineering and craft models of software development.  More on TSP later.  Right now I want to refer you to the article by Mr Humphreys.

Back in 2005, in Crosstalk, (thanks Glen) Watts Humphries addressed twelve questions around why large software projects fail and what needs to be done about it.  The article is a lead in to TSP as a solution to the challenges of large projects, and software projects in particular.  Go read the article and you'll recognise the themes.
The questions he addresses are listed below to pique your interest;
  1. Are All Large Software Projects Unmanageable?
  2. Why Are Large Software Projects Hard to Manage?
  3. Why Is Autocratic Management Ineffective for Software?
  4. Why Is Management Visibility a Problem for Software?
  5. Why Can't Managers Just Ask the Developers?
  6. Why Do Planned Projects Fail?
  7. Why Not Just Insist on Detailed Plans?
  8. Why Not Tell the Developers to Plan Their Work?
  9. How Can We Get Developers to Make Good Plans?
  10. How Can Management Trust Developers to Make Plans?
  11. What Are the Risks of Changing?
  12. What Has Been the Experience So Far?

14 September 2009

Iterations and UI Design

This article spurred a reflection on my experience with user experience and UI design on iterative projects.

In a few largish sized projects I have worked on we started with paper sketches done by me with 1-2 other people in a cafe. In a more recent example the draft UI framework was put together by a developer via three options. I then picked one with only a second's though. (We can always change later.)

Iterations usually come with presentations to users and as that occurs refinement and improvement opportunities can be identified and implemented.  And that is exactly what hapened.

In this model it appears that as long as you have some basic sense when it comes to user interaction, and when you are culturally aligned to your users, there is only so much more that a designer can add by way of value.

When you deliver iterativley, are UI experts needed, or is it a waste?

A caution; My users are usually paid to turn up and use the system. I am usually not deploying to public websites, but the poits here are still pertinent for that type of application.

11 September 2009

Design patterns

Up until about a year ago I had never heard of Design Patterns.  I learned about it shortly after I joined a team and the techies were in the process of  'interviewing' me.

In the time since then I have noticed many PMs and BAs I have spent with are unfamiliar with the term and concepts behind it.  No surprise really, as I had worked with I.T. projects for over 10 years as a 'business' oriented person, and I never got invited into the programmer's library.  Why should I expect everyone else has?

What is a Deign Pattern?  It is what it sounds like. I'll not go into detail explaining it, but will instead provide a short reading list.  Let' start with Wikipedia.
Patterns particularly relevant to me
Image care of Penguin & Fish cc at Flickr

10 September 2009

Architecture in the physical world

I was talking to my sister in law on the weekend about the software/corporate project problem (you know, high failure rates, etc) and she confirmed that much of these issues also face her colleagiues in the construction industry.

Two things came out;

1. They refer to a lot of predefined components in their design specs, and
2. They have trouble getting their clients to remember (and pay for) agreed scope,scheule and budget changes.

So, it's not just you.

Picture by  . SantiMB . and cc at flickr

9 September 2009

Storyboarding as a requirements tool

There is a lot in this for BAs and other requirements professionals.  (Thanks Matt.)

8 September 2009

Knol: Analysis of Project Success Criteria and Success Factors

Dimitrios Litsikakis has posted a knol on project success criteria.  You can go there and read it.  You can also edit it of you wish. The essay is broem into two parts.  the first section is on success criteria and the second is on  success factors.

Here is the headline list of success factors;
  • The PM,
  • the team,
  • the nature of the project itself,
  • the performing organization and
  • the external environment.
If that list is the case, then one of your risk assessment activities is to check the health of each of these dimensions and plan to put as much as is required into the weaker areas.

4 September 2009

When these things are ignored there is trouble ahead.

Roger Cauvin publishes a blog focused on product management, a topic very close to enterprise business analysis.

Last week he published a diagram from Pragmattic Marketing showing a framework for 'creating and marketing successful, market-driven products.'

The article is here and the diagram is below.

My question echoes Cauvin's challenge to Product Managers.  Why is so little done in relation to the areas on the left of this diagram.  My experience is that when the things on the left are paid attention to early enterprise projects tend to travel well.  When these things are ignored there is trouble ahead.

(Click the image for a larger version.)

3 September 2009

A requirements taxonomy

There is a lively debate going on right now in the requirements engineering yahoo group on what THE requirements taxonomy should be.
  • What is the difference between functional and business requirements
  • How can you have 'optonal requirements'
  • Where does solution agnostic requirement spec end and design begin
  • What do we mean by 'business'
  • Hell, what do we mean by 'analysis'
Al good questions.

Donald Firesmith dropped this classification model into the discussion today. It looks like this;
There is another definition of operational requirements:

1) Operational requirements are systems requirements that specify how the system must operate

2) Maintenance requirements (not maintainability requirements) that specify how a system (not just software) must be maintained (e.g., replacement of parts)

3) Sustainment requirements that specify how a system must be sustained (e.g., supplied with fuel)

4) Retirement requirements that specify how a system must be retired from service (e.g., disposal of hazardous materials).

It's a nice alternative to the way many of us think about requirements.

As an aside, I have been reflecting on the differences in types of requirements statements recently. In particular I have been sitting in review meetings discussing User Stories where I note two characteristics.

User stories are stuctured to be focused on capabilities, with an orientation to particular user types. This means that they can be quickly assessed to determine whether they are solution agnostic or assuming particular solution contexts. Also - since you are responding to a tangible emerging system there are often opportunities to go straight to a solution option.
An example: -As a customer-I want to be able to open up a search result and see more product details-so that...

This example may be a bit vagiue for you, but the people in the room know exactly what this means for an implementation.

2 September 2009

What software project managers can learn from road design

Vikas, a reader mailed me and told me about a blog post he has written.  It's uses principles of road design to explore some ideas of good and bad system design in project management.

It's a bit longer that my typical posts, but is pretty interesting. Take a look at what software project managers can learn from road design.

Photo by my mum, of my dad back in the day.