Search This Blog

31 August 2009

American industry is on the decline...

...and has been for 14 or 15 years.

W Edwards Deming offers some advice via 1984.

This clip nominates 5 management diseases. How have things changed in the last 25 years?

Thanks to John at CuriousCatBlog for putting this in front of me.

28 August 2009

Using the WBS in Scrum

The DoD handbook points us to defining three levels of a WBS when managing a project, and the same is probably a requirement for a supplier in that environments; show me the top three levels of your work breakdown so I have confidence you know what you are deliverring (and how you'll get there.)

My training - both in practice and education has always made me think very hard before going down to work activity level in a WBS.  The WBS tool is supposed to be about deliverables and like Mr Covey advises, we need to keep the end in mind.  So WBS items should always be focused on physical deliverables.

In practice in my non-militry career there have often been compromises to this principle and I am comfortable with this, becasue more important that WBS principles is the need to break up work into managageble and undertandable chunks.  Work with your team, sponsor and partners on the WBS and make the compromises where you need to.

But the principle of the top three levels being defined is very useful and not one to ignore.

I have the top 3 levels of my WBS defined right now and I am rnning a scrum project as close to vanilla as I can manage.

What are they?  The details are private, but it looks a little like this;

1. Business system solution
1.1 Software application A
1.1.1 Business Product X supported
1.1.2 Business Product Y supported
1.1.3 Business Product Z supported

1.2 Software application B
1.3 Software application C
What does this mean?

The business system solution is the business domain we are - for want of a better term - re-engineering.  It roughly equates to the way a department does business via a set of products.  Application A is one of a handful of software applications we are building.  It's a system of systems kind of thing.  Business Product X is shorthand for the mandatory (in Kano speak) requirements.

Where does the product backlog live?  At the application level - Level 2.  Then it's contents are grouped (guided via the minimum mandatory feature set) into releases that align with releaseable clusters of system capability.

Level 3 acts as a guide to what is important and does change over time.  But it is still serves as a tangible feature set per WBS item.  There is more detail below each of these, but it's details embedded within the product backlog - and that is suficient for the most part.

The systems are supported by independent teams and the product backlogs are orderred and grouped into pragmatic clusters of releaseable chunks.  But it remains dynamic once you get past the first release of a product (X,Y, Z) then you can pretty much prioritise whatever you want as the next releaseable feature.

This system misses something, and it's accomodated by a solution that feels wrong to me; a level 2 Change Management WBS item which kind of mirrors the product development WBS items.

What I think I would prefer here is that the training, documentation and communication activities were packed up in the product backlog and treated like any other feature and sat within that level 3 WBS item.

I am not running at aspect of this project and so what I like is beside the point.  Maybe next time.

Questions? Comments?
Picture by Leo Reynolds CC at Flickr

26 August 2009

Resource planning and estimating

Organisational capability affects how you resource a team.

1. In a low capability org you need more people.
2. In a low capability org you will face more resitance to the true cost
3. In a low maturity org yu are more likely to be staffed with low capability people

So, maybe there is some established formula someone could share with us. My guess is something like this (with real numbers.)

Staffing costs = x+n+y+z

x = Resources required accodring to your planning
n = Contingency based upon risk analysis
y = Organisational capability factor
z = People capability factor

Picture care of Jim Rees cc at Flickr

25 August 2009

Business requirements versus stakeholder requirements

A question was asked onthe Requirements Engineering discussion group about the difference between business requirements versus stakeholder requirements.

Can you answer that without looking the answer up somewhere?

It's a problematic question because the terms don't have plain english definitions; they are both jargon, and so you have to make your way through various industry definitions to find an acceptable, and probably compromised answer.

Let me run a few things by you;

'The business' is a term used by various technical service providers to differentiate themselves from the actual business they work for.  So your developers may call the BA team they work with 'the business' and the BAs themselves may call the sales and operations community 'the business.' (I haven't often heard it used to refer to senior C-level management.)

This separation of identity is problematic in its own right, but let's not go there today.

Frankly, 'the business' is an innacurate phrase and actually means 'stakeholder requirements' but with a limited view of which stakeholders are important.  Is it worthwhile trying to drop the use of this phrase?

Maybe, as it's true that not all stakeholders are equal and in fact understanding - or clearly calling out - the difference between a stakeholder requirement versus a sponsor requirement may go a long way to sharing the effort required to deliver your project.


24 August 2009

David Randall's BA SIG - How to be a BA success

In Sydney on August 27th?

Once a month David Randall, BA about town in Sydney hosts an ACS event - a Business Analysts SIG talk and discussion. I spoke once and this coming month a former colleague of mine, Phil Craig, will be speaking.

The August topic is "What to do to ensure your project is a success and how to avoid the pitfalls that can doom your project?"

The precis of the talk is as follows;

Research shows over 60% of IT projects fail. What are common causes of these project failures? As Business Analyst, can you make a difference on your project?

We present research by the OGC (the founders of the Prince2 project methodology) on the common reasons why IT projects fail.

We then take a a look at some of the simple things that you can do to help avoid the pitfalls that doom projects to failure, and increase the odds of delivering a successful project.

Event details;

Date & Time
  • Thursday 27 August 2009
  • 6:15pm for a 6:30pm start - 7:30pm
  • Sydney Mechanics School of Arts
  • Level 1, 280 Pitt Street
  • (Between Park & Bathurst Sts)

The event is free and open to all walks of life. You don't need to be a BA to get value from these sessions.

Photo by constantly_Jair and cc via Flickr.

23 August 2009

Distaster stikes twice

Two of Australia's most high profile organisations, the Tax Office and Telstra, are both suffering from a common project problem.  But don't worry.  They're deeply committed and the heads of the programmes are figuring on biggering...

"More than 3300 change requests have been issued"

Classics that should have their details made available as case studies.

The common themes to these two project disasters includes accenture, but they are just a body shop. The real problems are systemic and deeper than the systems integration lead.

A manager's checklist

From Jurgen at

21 August 2009

Turf Wars: Is Project Management a Profession?

If the post on whether project management is a profession piqued your interest read this paper;
The upside for professionalisation is that the name "project manager' gets protected and people can't just use the label willy nilly.   That shuld correlate into better pay for project managers as the true professionals in the community are able to stand out through their use of a reserved title and of course due to the supply/demand factor that comes with profesisonalism.

The downsid is that you end up with a higher duty of care to your clients, so no more budget and schedule blow-outs than you very much.

When you reduce the arguements to these summary points it seems it is in the best interests of 'professional' project managers nd cients to have the role become a profession.

But with such a huge demand for project managers the need to materialise them out of somewhere would mean a numebr of low grade trainng and certification operators would probably end up in the industry also.  Just like with lawyers, clents would check out where you got your credentials andthis feedback loop of privelede and class would infiltrate the industry.

Is there a better way?

Picture by Steve Punter cc at Flickrand graphic from the paper referenced above.

20 August 2009

Is Project Management a profession?

Is Project Management a Profession?

Below is a list of articles and opinion pieces on the topic of whether project management is a profession.

Is Project Management a standalone profession? (or will it ever be?)  What do you think?


Joseph R. Czarnecki; “They [PMI] they have helped to establish project management as a profession

Dennis Stevens; “By any definition, Project Management is a profession.

Josh Nankivel "We should be trying to improve the success of project management"

Will be

Hal Macomber; “Nothing is more important to the success of projects than the on-going upgrading of skills of the project managers.


Paul Ricthie; “perhaps we should never say never

Won’t be

Bas de Baar; “It shall be promoted as a core competency needed by all the personnel working in the organization so that they can successfully work in groups and help organization in achieving its goals.

Demian Entrekin; “Like most movements, the goal is always more disciples.

Dr Paul Giamamalvo “It is considered by the majority of its practitioners to be a process, methodology or system

Ed Naughton; “People who successfully complete MBA programmes do not consider themselves as part of the MBA profession.

Max Wideman; “[PM] is a very important discipline, one of several falling within the overall domain of general management.

Questions for you; Is management a profession? To what degree does this question matter to the way you conduct your work? Do you have a set of professional standards? Do you know the boundaries of your capabilities?

And a question for the business analyst community; Do the same arguments and conditions apply?

I'll wrap this up with a  quote from Glen Alleman; "I’ve come to the conclusion that the topic is a dead end with no benefical outcome to the business we work in other that to spur more debate."

Photo by Keith Allison via cc at flickr.

17 August 2009

Creativity never hurts

If you can explain 5 hours of movie in one graphic, why not a software application?

(Click on the graphic for a larger version)

Where are the creative requirement specs?

15 August 2009

Mercenary Analyst

Care of this post I discoverred this presentation which lead me to this idea;

Design specifications and system documentation may be better done by a short term contrator who has no direct stake in the system.

Why? They arn't pushing any particular agendas and can stay out of the way of the people doing the system work.

This does not preclude the importance of, and the role for, identifying and articulating business requirements.  What do you think?
Photo by  MATEUS_27:24&25 via CC and Flickr

11 August 2009

Pair Programming Primer

"The corollary of constant change is ignorance. This is not often talked about: we computer experts barely know what we're doing. We're good at fusing and figuring out. We function well in a sea of unknowns."

- Ellen Ullman (1997) “Close to the Machine: Technophilia and Its Discontents”, City Lights Books,

10 August 2009

Diversity versus Unity

Diversity of experience and backgruond is good. It brings differnet points of view and differnet ways of thinking about problems. It can also equip you with a wider range of skills han you otherwise may have on the team.

The downside of diversity is that the people are different. Often in projects we come together for one project, maybe two and then move on in different directions.

This means teams are alasy forming anew, building trust and modes of cummunication that suit them as a new group.

And this means conflict as norms and values are formed. (You remember forming, storming, norming and performing, right?)

Is the benefit of diversity worth the cost of reforming teams?  It probably depends on the situation, but in most cases the answer appears to be yes.

Take a look at this aper from Harvard's Huckman and Staats;
What's your experience with forming teams?  When do you look to mix a team up, or when do you try to keep the team together for the next engagement?

9 August 2009

The effect of values on system development project outcomes

It's a cool and sunny Sunday afternoon and I am on the couch reading Dan Ward's thesis on the importance of values in project teams.

It's such a good read that once I finished section one, I had to fire up the compuer and tell you all to go read it.

Maybe I am biaised because this is a very clear articulation of the values that I tend to, so it's reinforcing a set of beliefs and values that I already hold.

Here is one of several great quotes;

"People think that big is better.  It's not" (Hillaker)

This line is in a discussion about the dysfunctional situation of non-aligned values of the customer who wants it fast, cheap and good and the project manager who is personally rewarded based upon how large the schedule and budget and, and complex the end system is.

This issue is at the heart of the project industry problem.

7 August 2009

20 Reasons why managers fail

The world is full of smart people who are sharing their knowledge and wisdom. Here is an example.
Read this list and assess yourself against it. 

While you are at it, have a think about your own current manager, team and key stakeholders.  How can you help them improve their game (and thus your own performance?)

Most pertinent for me right now; points 7 and 8.  You?

6 August 2009

Sponsors perspectives

Emperor Palpatine was the sponsor for one of the largest projects ever, and yes, the first project attempt was low on quality and the second was over budget and schedule.

Hear how a project sponsor feels about these projects.

3 August 2009

Earn a discount to your next PM training course.

On Monday I told you about eCornell’s course A Systems Approach to Product and Service Design

Caitlin, who got in touch with me about the course has arranged a bunch of discounts on the course to go with a competition.

The competition is going to be about project horror stories. 

Send us your horror story of a project gone bad and the best one will be selected and published here and on the eCornell website. (Made anonymous if you tell us to so you can tell the real truth.)

Enter this competition and you automatically get $100 off the course fees.

The winner’s story will be published here and will receive a 10% discount on the course (worth up to $375.)

These benefits are on top of an ‘early sign-up’ discount of $375and you can save up to $750 of the course fees.
Email your horror story to Caitlin at  Entries close on September 15th and the winner will be announced that week.

Picture by JustABigGeek CC @ Flickr

1 August 2009

A quote

It is difficult to get a man to understand something when his job depends on not understanding it.
- Upton Sinclair

Power and influence

Project stakeholders are an interesting bunch.  In many organisations and on many projects sponsors manage remotely.  They care about the budget, schedule and scope, but only at a high level.  The details are for you to work on.

The reasons for this are many, including the facts that senior managers are busy, that they are remote from the engine room of the operation, and the fact that many projects are not sufficiently important for senior managers to be intimately involved.

In these cases driving requirements and acceptance of the project's output is often referred to middle and frontline managers.  These are the people who you work with in Working Parties and in the day to day business of managing the project.  They are the people that come to mind when you say 'stakeholder management.'

These are also the people who get to say whether what you produce is sufficient to be rolled into their operations world, possibly by mechanisms such as user acceptance testing or acceptance certificates.

There are a few problems with this model.  Can you pick them?