Search This Blog

30 April 2009

What are you delivering?

A software product?
Business capability?
A solution to a problem?
A set of benefits described in a business case?
A service to a bunch of people?
A service to one person?

How are you measuring your performance?

Pic by marmota, CC @ Flickr

29 April 2009


Alignment problems are usually thought to be horizontal: The infrastructure team aren't in line with the applications team, or the requirements team don't properly undestand the business, or the developer team have misinterpreted the design...

Does this sound like a problem you have encountered?  Was it the biggest problem on the team at the time? I suspect it wasn't.

I suspenct that the biggest gaps in alignment are vertical.  And that means senior management don't understand the complexities and detail of frontline operatives, and frontline staff aren't clear on the competing priorities of cost and quality.  As a result they are in conflict over project requirements and success criteria.

What can we do about this?  Do we take a position aligning with one side or another, or do we broker understanding.

What should we do?  What are you doing?

Picture by Mamzel*D,cc @ Flickr

28 April 2009

The Marketing Mix and your product

You are working on a project and that project is going to delivery products and services.  So, regardless of industry, you are in the business of marketing.

Marketing is about configuring your assets an capabilities in a way which offes value to your client or customer.

So let me run a quick check with you on your product's health, via the marketing mix.

I am not advocating a full blown adoption of marketing principles into your project communications strategy, but I do think a reflection on some basics would help.

What will he users be giving up in echange for the opportunity to use your system?  Will they be paying money?  Will they be forgoing the use of a manual process for a semi-automated one?

Why is your product going  to make thie life better?  Does this benefit outweigh the cost of changing?

What about the project sponsor?  Are they getting value from your project?  How?  Is it value that they'll appreciate at the end of the project?

What are you doing to tell our clients and users about the benefits theyare going to recieve?  A project communciations plan is more than a list of project management weekl and monthly reports.  It needs to include the communciation efforts invoved in getting people to adopt your new products.

Ahh, the big one.  Are you focusing on the right features? Really?

If you had to halve the features today, which ones would you keep? 

Where will people be using your product?  WHat is the context tey will be larning how to use it?  How will they master it's feature set? What environmental things will help and hinder uptake of the product?

These questions are just primers.  Of course you could go further, and if you can, I think you should.

How are you marketing your product?

27 April 2009

Capability first, methods second

I’ve worked in three different kinds of organisations I’d like to tell you about. Two of them ‘got’ project management, one didn’t. All three can be said to be largish, with more than 20,000 employees.

The first was a market driven company that developed products for customers and also developed back office and sales support tools for its staff. The second was a large and slow moving company that had an absolute passion for control and discipline. The third was an organisation that didn’t really know what it wanted beyond the whims of the leadership team.

Each of these suits a different style of project management.

The first example was a telco during the deregulation of telephony and the growth of internet products, the second was a bank during a time of increasing competiton and shrinking margins and the third is the public sector.

Each of these organisations had different goals. The telco’s main goals were market share through product innovation and trying to keep revenues ahead of costs. The bank’s goal was cost minimisation and risk minimisation while maintaining market share, and the government's goal is risk minimisation and stability.

These goals had a strong influence on the organisation’s culture.

When looking around at the project challenges these organisations faced the things that stood out was that the telco and bank were mainly about optimising project processes. They also had pretty good strike rates across their project portfolios. The government didn’t.

You could say that the telcos are ripe candidates for the fast to market values of the agile pm crew, or that the bank is a great candidate for PMI style thought-through project plans and disciplined, but expensive, execution. You could also guess that a very process oriented approach to projects like PRINCE2 would suit governments. It strikes me though that PRINCE2 and it’s cousins transform much of what a PM does into a spectator at a train wreck.

I want to try to not just sedge the government and it’s organisations because they are full of talented and good people. But they have an almost insurmountable obstacle between the way they operate today and the project management business of getting things done.

Government departments are bureaucratic. But so are banks.

The bank I worked at for example was a CMMI level 5 organisation. It knew paperwork and process like I know the back of my hand.

Governments on the other hand are real bureaucracies: The kind that work at stopping things from getting done because that means change. In government the propensity to fail conservatively is taken to new extremes. People actively set up networks to help them stop change from succeeding.

Take, for example, Sir Humhrey.

So, while much of the project management methodology discussions focus on fast to market agile versus the integration benefits of planning, the big question for many of us is; what do you do if your client organization has no project management maturity whatsoever?

For example, what is the purpose of a well thought through plan if it has no forum for base-lining and no discipline around change control?

What is the value of budgets and schedules when the sponsor simply wants an undefined “it” done by an arbitrary deadline?

What should the project manager's role be in this context?

These question has been with me for a while, and has most recently been stimulated by ongoing discussions at blogs such as Herding Cats, Inquiries into Alignment, Project Shrink and Noop.

What are your thoughts?

26 April 2009

How I failed

An interesting reflection on a personal failure.
While the lessons learned are interesting in themseleves, the big question is:

Would you? Could you share your failures online?
Could you, would you swap your lessons for mine?

24 April 2009

Bohemian Rhapsody

This will impress you.

Not all great IT solutions start with reqirements. Some start with the ingenuity of one crazy programmer.

22 April 2009

I (heart) Stephen Jonathan Whitty

Wil points me to another fascinating article by Stephen Whitty.

    I am seriously happy this guy is wrinting about project management.  Overall, his work is a very fresh and potentially brutal assessment of project management practice.  And yet, he's "one of us."

    His work has been referenced here at this site before (and probably will be again.)

    And you can easily find more of his stuff via google.

    Definitely a step up from the "What is a WBS" type articles out there.

    20 April 2009

    Tracking this and other blogs via RSS

    This video is care of Bas de Baar at It explains how to use Google Reader to track RSS feeds. I hope it is useful for some of you, and that maybe a few of you sign on this this blog via RSS readers.

    19 April 2009

    Lessons Learned

    Post implementation reviews, retrospectives, customer feedback... All great ways to learn about what you did and didn't do well. Reflect and learn.

    Or shortcut the process and go read about other people's mistakes before you repeat them.

    The Mistake Bank is a new(ish?) online community where members get to share their own failures.

    Picture by Caro Wallis, CC @ Flickr

    17 April 2009

    Compound interest

    Writing a business case?

    Take a look at this lecture on compound interest. Fascinating stuff.

    16 April 2009

    As an Business Analyst I want to... So that...

    Barbara at B2T has started a discussion for business analysts on user stories.

    Do you know what User Stories are?  Do you have any ideas whether they are good, bad, neutral?  Would you swap out a use case for a user story? Have you moved off in other directions?

    If you are using user stories, do you have techniques to keep them sharp?  Have you had trouble implementing them on your project?

    By the way, I'll be speaking at the 2009 BA World Symposium in Sydney and Melbourne on this topic.

    Picture by Tojosan, CC @ Flickr.

    Requirements walkthroughs

    Laura Brandau has written a piece explaining why walkthroughs of project requirements are not always a good idea. I thought I'd add my take on this.

    "By eliminating a “best practice” and replacing it with an open-minded acknowledgment that there are multiple paths toward achieving alignment, I feel confident my work on future projects will result in more meaningful approvals and scope sign-offs."

    Read her article before you read my comments. It's got some great insight.

    Now, some things I have done at various times that are 'non-standard' but seem to have worked.
    • Spend time in conversation with your stakeholdes and demonstrate to them that you understand their business and have their interests at heart (and that you are technically capable.)
    • Facilitate discussions between developers and client/SMEs to open the communication to another level
    • Use business processes as a common language and contect, and drop jargon (heresy for OO/Use case fans?)
    • Put it all one one page, and use that page as the main conversation tool
    • Break the product into releases or parts to simplify the discussion
    Any other ideas?

    14 April 2009

    Project Management Ethics

    Maybe one or two or you are working in what Carnegie Mellon might call a 'level 0 capability maturity' organisation. (Or maybe level 1.)

    What you probably find is a lot of organisational politics and a lot of busy work and bad decision making.

    In this context it is hard to get things done, and particularly to deliver complex projects near budget and approximating the target benefits.

    So what do you do? Choose to not participate in a project doomed to cost and schedule over-runs, or do you get stuck in to it?

    And if you do choose to run this sort of project how do you manage the dilemma of knowing you are going to let the client and stakeholders down at some point?

    Photo by Eduardo Amorim and CC @ Flickr

    12 April 2009

    A TCP/IP metaphor

    Rob threw me an idea the other day.  It's about the reasons why different project team members need to communciate with different business stakeholders.

    He equated project communications to the different levels of communications going on in a TCP/IP process.

    Think this through: you write a message, software breaks up your message and distributes it, and other layers of the process physically carry electrons pulsing around the globe to your reader where tings are re-assembled, formatting and all.

    So what's going on in projects?

    Project manager & Sponsor 
    Talk about goals and strategy

    Analyst & SME/middle managers
    Talk about features and process

    Developers & users 
    Talk about user experience

    What's your take on this model?

    Photo by skoop CC @ Flickr

    10 April 2009

    A review of the latest PMBOK

    A quote:

    My opinion is that the PMBOK® is as out of control as your most nightmarish stakeholder. Always changing things… hoping to make it better… when in fact they have seem to add complexity with little or no additional value. As Voltaire stated "The perfect is the enemy of the good."

    Read the rest of James Brown's article here.
    (Thanks for the referral Glen)
    This photo comes, CC as usual from Flickr care of Erik J. Gustafson.
    PMs may want to go check out the photo commentary.

    7 April 2009

    Alistair Cockburn on Earned Value and Product Burn Charts

    A big challenge in implementing agile practices is overcoming prejudices and managing the language/expecation gaps - to stop them becoming barriers to getting work done.

    One tool to help people is the close links between agile burn charts and project management's earned value. Inspect the two models, they are almost identical as far as the outcomes they generate.

    Cockburn's article is here.

    Picture by Tracy O, CC$ Flickr

    6 April 2009

    Hey, well done project managers!

    I was talking to a few graduates the ther day about project management and heard myself making the statement that most good project managers found their way to their current job mainly by being good at getting things done.

    It got me thinking - most PMs I have met are good, hardworking pragmatic people. There are always exceptions, but it does feel like an industry populated by a large number of high quality people.

    Colleagues, forget the industry failure rates for a moment and take a bow. Without you things would be an even bigger mess.

    Now factor in the industry failure rates, and realise that most of the barries to success are clients not listening of paying due care in their business and - hell, take an encore bow.

    It's usually a thankless task, but definitely not an easy one.

    Photo by ►Voj►, CC @ Flickr.

    3 April 2009

    This week at PM university

    I am back at MIT (Sydney) teaching project management. This week at university (week 2) we talked about project initiation, prioritisation and portfolio management.
    In the classroom we ran an excercise. The class broke up into six groups who went to work on developing an idea to improve our imaginary business "The Worlds's Best Ice Cream Company."  The creativeness and variety of the proposals was fantastic and many of the pitches were as good as some I have seen from experienced PMs.

    The four gentlemen you see above took on the role of the project governance board.  From left to right they are the head of sales, head of finance, CEO and head of operations.  They took to the roles with gusto and watching them probe the teams that pitched projects at them reminded me of some project boards I've seen.

    All in all it was a fun and interesting class. When I ran through the slides in the last 30 minutes of the lecture I could see we had already addressed most of the major points, apart from the detail of financial analysis tools.)

    Great work class.

    2 April 2009

    BABOK 2 now available

    The International Institute of Business Analysts has published version 2.0 of their Business Analyst Body of Knowledge (BABOK.) The IIBA has a similar momentum to the PMI a decade back and so the BABOK is likely to become a BA equivalent of the PMBOK.

    It is full of information about the requirements management process, from identifying organsiational situations that give cause to a project, through to starting the requirements gathering process, to delivering a solution to your business or client. Processes and techniques are both coverred.

    Experienced practitions will probably recognise many things, but will probably discover a few new tips. Novice analysts would benefit from a thorough read (followed up with a discussion with your peers.)

    And project managers would also benefit. In two ways.

    1. You are often called upon to do the requirements management work at one level or another in your projects and you can pick up some of the techniques and employ them, and

    2. You'll have better insight into the processes and practices of your BA team, and be better able to work with them in the future. Probably as a more understanding consumer of their work, and as a coach.

    So, if you are a member of the IIBA - it's free, and if you are not, then it's only US$29.95 (or about that.)

    Photo by Jeff Tabaco CC @ Flickr

    A wak in the fog

    Rodney Turner put together a simple taxonomy of projects, based upon two questions;
    • Do you know what you want?
    • Do you know how you'll get there?
    From these two questions you get one of four typs of projects;
    • Painting by numbers
    • Making a movie
    • A Quest
    • A walk in the fog
    The skills and practices of project management (whatever flavour) is most suited to the Making a movie and Quest modes.

    Painting by numbers is regarded as fairly simple and potentialy you can get away with just plain old common sense.

    A walk in the fog is a metaphor for someone who is lost.  In this case traditional project management can help you get to your unknown destination quicker, but you might not actually want to get there.  The agile/iterative approach may be a better bet in these cases, as you shrink the steps and thus the risk of heading in the wrong direction.

    Which quadrant does your project fall into?  Where do you want to be?

    What do you need to get there?