29 July 2008

Valuable requirements

Projects are often supported by unrealistic business cases.

Many are overly optimistic.  Some are overly pessimistic.  Most are full of educated guesses (and some are not so educated.)  Many are trying to justify the project on only financial value statements. 

Let's start with first principles. 

Projects should deliver value to the clients.  That value can come in financial and non-financial ways. 

If the project is aligned with strategic imperatives then it is probably a better use of resources than a project that isn't contributing to strategy. 

But you also have to balance capability with desire, so some projects do end up being about quick wins and what we can do, rather than what we should do.  This is managed through a project portfolio approach.

So now I am getting to the trigger for this post.  I was browsing Scott Quick's website and found this quote from Forrester;
    "Successful packaged apps strategies require business process and applications professionals to align with corporate business drivers. But because business drivers for individual IT projects often shift with time, the portfolio of apps initiatives requires organization and alignment by economic state and project risk. Once alignment is achieved, business process and applications professionals should identify the high-priority initiatives that best align with current business drivers and create a business technology (BT) value plan that connects the dots between corporate strategy and application tactics."
Changing corporate business drivers?  Prioritise the important things first?

Sounds sensible to me.

The agile software development crowd have a solution for this - it's Scrum's product backlog and short delivery cycles.  But you don't have to use agile methods to address this issue.

Everybody is familiar with prioritising requirements and there are dozens of models to help you do this.  The problem is that many people get caught up in the optimum solution versus the bare-bones delivery paradigm.

It doesn't have to be one or the other.  It does end up that way if you don't prioritise your work properly though.

Each requirement line item has to be mapped back to the business strategy, and it must be clear about what the value it brings.

My personal bias is that I feel requirements often get convoluted and very detailed and so lose their relevance to business strategy and goals.  So for me, another important issue is in maintaining simplicity and clarity of your message along the project value chain.

So, how about it requirements managers, can you do that with the set you are working with today?  And if not, what needs to be done to improve things?

Maybe the thing we need to include in all our project documentation is a value management plan?

Image care of Soundman1024, CC and Flickr

28 July 2008

An introduction to Six Sigma concepts

Six Sigma is a packaged set of proces improvement tools, and integrated into a fact based decision making model. Software and business process improvement projects could easily be bracketed by the define, measure, analyse and control processes that Six Sigma advocates.

Six Sigma may be on the back of the hype curve by now, but there is still plenty of value to be found in the model. If you don't know much about it, and are curious - here is a slide presentation that gives a good quick oveview of the key concepts.

27 July 2008

Chaos and incremental improvements

The infamous CHAOS report by the Standish group highlighted the abysmal performance of the projects industry in 1994.  Over the next decade they continued to publish several versions of the report, highlighting both improvements to the projects industry and the areas of risk or high performance.

Here are a couple of snapshots from the original in 1994 and more recently 2002.

(OTOBOS is a phrase I learned from Elizabeth Harrin- On Time, On Budget and On Scope.)

So what is this improvement due to?  If you have a look at the issues reported as failure and success criteria over the life of this report you see there are a number of key things that changed - most prominently the professional (usually PMI or PRINCE2) training and experience of the project manager.  The second key issues that seems to have contributed to this imrprovement is sponsor engagement and support.

The thing is - this improvement is just incremental.  There is plenty of further opportunities ahead for us.

Examples include shrinking the size of projects to something that is manageable, and making sure requirements are properly managed right through the project lifecycle.

The Agile Alliance and the IIBA are taking steps to move the industry in these directions.  What else can be done?

More particularly, what are you doing?

25 July 2008

Wordle - a word map for Better Projects

This seems to sum up what we have been talking about recently.

From Wordle.

24 July 2008

Out of Control

Christina asks what to do when you take on a project that is, frankly, out of control.

At the top level you have three options;

1. Quit and go work somewhere less chaotic,

2. Step in and be guided by the people and procsses already in play, and

3. Put aside the day to day busy work and address the key problems.

Let's presume you pick option 3.

I've written about this in the past and my opinion remains the same; the thing to do when you join a project - where the wheels are spinning but nobody's moving - is to start with risk management.

Basically the project risk management framework puts a structure in place for you to identify risks to the project (particularly time, budget and scope) and to get people to help you tackle them.  Especially your sponsor and steering committees.

It works because it is structured and formal and makes the people around you accountable for doing the right thing, rather than just what they were planning to do. It's also a good way to zero in on the critical items that are not urgent but are lurking around the corner - and need to be tackled.

That's the strategy, but in some places it's hard to find the time to deploy it.

So four more suggestions;

1. Get help. 

Pick someone in your team and enlist them in your risk management mission.  They do the paperwork and organise meetings.  You do the leading, motivating and investigating to help get things moving along.

2. Don't be afraid to put other things aside.

There is often scope to drop administrative tasks such as weekly reports, meetings with team members or non critical stakehodlers. Think about whether meeting with these popel is substantially contributing to your project's goals or is just taking up yor time.  Delegate or cancel.  You have more important things to do.

3. Force a rhythm.

If your team are busy but not focused, and if the same applies to you, a quick way of getting things structured  enough to give you breating room is to set a rhythm to your teams work.  Pay attention to the natual rhythm of the project and organisation and set your cycle of events to match that.  Make one of your regular events the risk management activities.

4.  Don't sweat lost time

Often people are scambling to meet missed milestones.  They'll never recover.  Better to admit the slippage and focus on regaining control.  Otherwise you'll just keep spinning those wheels in the sand.

Anyone else got ideas?

(Picture care of Léoo™, CC and Flickr)

23 July 2008


Today I was listening to a panel of educators discussing where things should be going in schools.  They talked about the concept of enabling skills.

These are the skills that set up a student in their early years so thyey are better equipped for learning in the mid and latter years.  Typically numeracy, literacy and problems solving fit into this set.

It got me to wonderring what the enabling skills are in our profession.  What do you need to know first in able to set yourself up to continue to grow and improve in your role?

I suspect it's not the obvious candidates.

Dear readers - I'd love your comments on this one.

(Photo care of John C Abel, CC and Flickr.)

19 July 2008


Nathan from SNJ Tech Consulting provides a couple of articles you might like to read: 
G’Day G’Day

Here are some of the best articles I found this month.
If you want to advance in your career, you need to make sure that both your online networking efforts and your overall Web presence are working for -- not against -- you.

Hard lessons from the coalface…

Open Source and the War for Talent - how the opportunity to work on open source projects helps attract top talent.

Not all IT jobs are being offshored and outsourced. Some positions in IT are among the most recession-proof jobs across all fields.
Recession-Proofing Your Career in IT  (US Economy)

Picture care of TailspinT, CC and Flickr

18 July 2008

Project Sponsor: job description

The Sponsor of a project is (usually) your primary client.  But they are also a team member.

Around here we like to think of project professionals as a service industry people – you’ve been hired to provide your professional services to delivery a high quality project.

The sponsor was hired to do a job also – and they have a service obligation to you.  Well, they probably weren't hired to specifically be a project sposnor, but they were hired to solve business problems and one of the tools they have picked is your project.

You already know some of the sponsor's role by rote; they provide strategic goals & measures of success, and the clear obstacles & provide an escalation point within the organisation

But a default job description always needs customising.

If you were writing a job description for your sponsor, what would it say? And how would you measure their performance? And how is your existing sponsor going?

Do they need a hand?

Photo by Melbourne Puppetry 

care of CC and Flickr

16 July 2008

Lore of Wizards

I have to share this website with you.

Lore of Wizards is a collection of stories from senior consultants.  Chapter by chapter a book is being released online.  The latest chapter (4) is Managing Client Relationships.  Previous chapters are "How We Got Started", "What it Takes to Succeed" and "Dealing with Clients."  You can access them here.

What I really like; the variety of stories from the elder statesmen of our industry. Wisdom.  Simple messages.  Not trying to sell you something.

The writing is simple and lovely.  The stories range across many perspectives and topics, clustered by the chapter themes.  Here is an excerpt to tease you into clicking through and reading it yourself.

So I took the extra thousand.

I worked in my dad’s business after I got out of school, followed by a stint in the Navy. I had an accounting degree and really wanted to be an auditor. In 1968, a friend of mine, a fraternity brother, called and suggested I try to interview with Arthur Andersen. I did and was very impressed with their approach. I liked their attention to people and professional development. I hadn’t really seen anything like it before. They also said they would pay me $11,000 to be an auditor or $12,000 to be a consultant. I had a wife, one child and another in the oven so I took the extra thousand. And that's how I became a consultant.

Taking the job meant moving to New York from Pennsylvania where I was then working. We didn't have any money and my wife was very pregnant and I had rented this apartment in New Jersey for $190 a month. It was a very small two bedroom with a leaky roof. We had two women of ill repute living below us who entertained people at all hours of the night. The first time my wife saw the place she cried. But it was the only place we could afford and we lived there for three years. 

I’d been working in factories and had ripped all the pants for my suits. So I had no suits, just sport jackets and slacks. Of course, you had to wear a suit at Andersen, so we scraped together all the money we had and I bought myself a suit. On the very first day of work, it rained. I mean it rained big time. And I had to wear that suit every day for two weeks, until I got paid and could buy another one. My wife ironed it every night for two weeks.

Photo from Davisayer, CC @ Flickr

5/5 - Full Marks for trying!

What kind of people pick up projects midway through? Especially the ones that seem to have all the hallmarks of a failed project right up front?

People like me, that's who. But why? Could it be a desire for stress? A need to stay back and work late regualrly? The love of paperwork?

I wish I knew. Maybe it's a combination of timing and the desire to test your skills. Maybe it's just dumb luck.

PMHut re-publishes (with permission) many blog posts on project management. If you want to look up a concept or idea - go there and use the search tools. If you want to keep abrest of what many project management bloggers are writing about, subscribe to the site.

Well, maybe it was really 4/5.

If you want to know what sort of project I have walked into recently - take a look at this post by Thomas K Casey.  (It explains this post's title.)

15 July 2008

Thi month's reader survey

This month's new survey asks about your orientation; technical or business. 

Yes, sure you want to say both, but you have to pick one!  Which will it be?

(For previous survey results click here.)

14 July 2008

Test Driven Development

This presentation is a tutoial for Test Driven Development, one of the techniques propogated by Agile Software development enthusiasts. in fact it is a useful approach for any software development effort, and it also has lessons for quality assurance of other less technical work.

Book Review: The Black Swan

The Black Swan: The Impact of the Highly Improbable

by Nassim Nicholas Taleb

This book is definitely a useful read for anyone who has a job where they need to plan for the unexpected. This is a look at statistics and how they can fool people into believing they can safely predict future occurrences. Mr. Taleb takes examples from science and finance like the titular discover of the black swan in the 17th century and the stock market collapse in 1987 and delves into why they were not predictable.

From a business analysis and project management perspective, this book is an excellent way to get you started thinking about risks and risk management. It reminds you that past performance is not necessarily an indicator of future performance. It also explains why statistics are not sufficient for fully predicting possible risks.

For me, this book got me thinking about the unexpected occurrences that can ruin a project. You can only plan for as much as you know. There is always a risk of a Black Swan showing up to throw a monkey-wrench into your project and somehow you have to account for that possibility.

13 July 2008

Dear Bas - Conversations with the Project Shrink

Where does the time go?

In the last few weeks Bas de Baar and I have been chatting across our blogs about project management. A couple of the areas we have touched on include training and accreditation. We are now moving into a discussion about some new project roles. Well, at least roles you don’t see on every project team. The idea of a project shrink, for example…


The project shrink idea you articulate reminds me on an ‘executive coach.’ For quite a few years now senior managers and middle managers with aspirations have been booking these coaches to help them reflect, learn and improve their performance. And of course there is the sporting analogy.

So let me see. A person is engaged by a project manager on a part time basis to help the project manager see above the day to day drams and look at the big picture. By helping we don’t mean doing, so deep expertise in project management would not be a mandatory skill set, but some experience wouldn’t hurt. A few war stories of your own help you understand your client and help you raise awareness of particular risks.

Now, this is a role which could be fulfilled within a number of other roles including a project manager’ direct supervisor, by a more senior colleague, or by someone from outside the organisation. Potentially it could also be played by a project sponsor. The trick is in understanding the need and prioritising time (and money) to the activity.

I buy the role is a useful one, especially as projects grow larger and more complex.

Selling the idea to my management is another thing though. They expect me to be an expert when I turn up to my first meeting. In some cases I am the one bringing pm expertise to the environment, so it’s all about levels or layers of pm maturity.

Let me ask you this Bas; Are you using a project shrink? And if not, what do you need to enable the role for you and your projects?


Bas and Craig have a weekly conversation, back and forth on their respective blogs, Project Shrink and Better Projects. With blog titles like that, you don't have to guess what the topic will be.


I made up the word 'properations' - for the situation where you find yourself in that no man's land between projects and operations.

Have you ever found yourself in this situation? The project should have finished, but just keeps on going? The scope is creeping you out, the client just isn't ready to take on the product, you just can't get that last sign-off...

For whatever reason, you just can't get to "done."

What did you do about it?

How can we avoid this situation?

12 July 2008

Hapy Flu

I picked up this little social networking bug from Graham's Knowledge Management blog.  Graham is writing a thesis on networking (more oriented to the group & people kind than data in cables.)

You can read the blog here - plenty of good stuff - which I intend to talk about in coming posts.

But before I do... the bug.

Graham's site introduces this little bug with the below content.  (Which saves me the effort of explaining.)

Matthieu Latapy is a network researcher at the National Centre for Scientific Research (Centre National de la Recherche Scientifique) in France. He is doing network research to counter peer-to-peer paedophile content - something I think we would all agree is very worthwhile!
Matthieu is conducting an experiment aimed at understanding how a real-world spreading phenomenon occurs via links between websites. In particular he notes that information diffusion is increasingly orchestrated by bloggers instead of the mainstream media. Matthieu's experiment takes the form of a viral marketing approach - hence the name Happy Flu.

To participate all you need to do is:
  • click "spread it" on the image above, 
  • enter your url, 
  • copy the code that will put the image onto your website, and
  • create a blog entry and paste the code into that entry.
The image you see is the diffusion path of the code, which should change as it spreads.
Go on - help Matthieu and spread the Happy Flu. Any research and experiment that combats paedophile content must matter!
Regards, Graham
So, friendly bloggers - your turn.

11 July 2008

Managing people, managing projects

There is a theory (reference anyone?) that management is about planning, organizing, motivating, directing and controlling.

And PM processes are gernally described as initiating, planning, executing, monitoring, controlling and closing.

See the similarities? See the differences? What makes projects special?

Where does leadership fit in to the picture?

10 July 2008

Reader Survey: Planning orientations

For the third Better Projects site survey I asked about planning. Specifically, the question was about how you orient your planning activities.

“Think about your work (project?) plan. Are you focused on activities or outcomes? Be honest now.”

I had 63 responses and they cam back like this;

  • Activities (Process drives consistent quality)   19 (30%)

  • Outcomes (Start with the end in mind)   34 (53%)

  • What plan (I'm adaptive)  10 (15%) 

What Plan?

The 10 responses to what plan are a bit alarming for me!

If this was your response do me a favour – reply to this blog post and tell me why.

My assumption is that you answer was either tongue in cheek, or you really don’t plan your work (and I expect you are more likely in the BA reader pool than the PM audience.

BA’s – you should be planning your work in as much detail as anyone. It’s complicated, and dependent on many external factors. As a result planning is a vital activity to help your work integrate into the overall project schedule and expected outcomes.

Activities versus Outcomes

Well, people...

The research has been done and while at a macro level, process orientation is important, and possibly even a long term indicator of success, the important thing for projects is to focus on outcomes. It’s even one of Stephen Covey’s seven effective habits; ‘Start with the end in mind.’

For further information on this idea take a look at Josh Nakivel's blog.

Now, if you disagree - I'd love to hear your argument for a process over outcome orientation.

Something old, something new (Requirements again)

Consider your project and its requirements specifications. Are they new and unfamilar or is everybody working within tried and tested boundaries.

In thinking about this issue I have created a model that divides a project into the dimensions of the business requirements (ie processes) and the solution (ie technology.)

These two dimensions frame how familar or unfamilar your stakeholders are with how your project is going to go about it's business. And this familiarity will drive particular behaviours and risks.

For example, if you are using new technology and addressing new business processes you have an opportunity to be quite innovative as you don't have as many constraints as (many) other projects do. Take advantage of this.

If, on the other hand you are dealing with existing processes and will be using existing technology infrastrcuture to solve the problem you face many constraints. On the other hand, everybody knows the territory, so you should be able to work through design, development and validation activiteis quicker than in other cases.

Where does your existing project fit, and how does this drive design decicions, and project management processes?

Photo courtesy of
Diagram by me

9 July 2008

Net Present Value

I have to tell you, this is a topic that I am no expert in. I rarely actually put togther NPV calculations. Usually where I work a finance person will do them rather than a pm.

But I need to be able to explain it to people.

I can explain this; NPV is a way of assessing differet projects over different time periods. It helps pick and choose what goes into your project portfolio. It helps understand whether the project meets the opportunity cost thresholds your organisation has set.

And the calculations themselevs are easy enough once you know how to use the excel NPV feature.

But explaining it still stumps me. This is me having a go.

Someone - Help me out and do a better job.

8 July 2008

"Mistakes will be made"

In 1948 William McKnight gave this advice to the people of 3M:

As our business grows, it becomes increasingly necessary to delegate responsibility and to encourage men and women to exercise their initiative.

This requires considerable tolerance.

Those men and women, to whom we delegate authority and responsibility, if they are good people, are going to want to do their jobs in their own way.

Mistakes will be made.

But if a person is essentially right, the mistakes he or she makes are not as serious in the long run as the mistakes management will make if it undertakes to tell those in authority exactly how they must do their jobs.

Management that is destructively critical when mistakes are made kills initiative.

And it's essential that we have many people with initiative if we are to continue to grow.

(Read about him here.)

I post this because in many projects and in many organisations the game is set up so that you play by a certain set of rules, which in most instances also set you up to fail. Don't be afraid to break away from pre-defined processes and approaches when it's the right thing to do.

You have been hired because of your expertise. Part of your responsibiliy as an expert is to apply your judgement to the obstacles and opportunities that come your way.

And, of course, learn from your mistakes.

Starting from Scratch

At my office, we are currently working on reinventing ourselves. We are looking at the work we do and reorganizing ourselves to do it better. This means we have moved some departments into related "functional areas" and added an Oversight department.

This all seems pretty straightforward until you realize that we have never really had a single group with the responsibility of seeing "The Big Picture" and managing projects through the maze we call an organization. This is not day-to-day project management, this is oversight of solution providers who do project management as well as managing budgeting, feedback, procurement, and contracting processes. It is not simply a PMO but it definitely involves many PMO features.

As the Business Analyst involved, I am involved in creating some of these processes from scratch. But where to start?

So far, we have:
  1. Created a functional statement
  2. Identified major processes at a high level and
  3. Identified interaction points with other groups.

Between my own experience and the resources I've found online, I've made some suggestions on what to do next and we have made a plan. However, I'd love feedback from this community to see what advice you have on the next steps to take. Any hints, tips or tricks? Any major gotchas to watch for? Any sympathetic stories to tell? I'll take any and all information I can get.

6 July 2008

Span of Control

Span of control (made famous by Peter Drucker) is a concept that looks at the number of people a manager has directly reporting to them.

This view of organisational structure has two dimensions, which each have strengths and weaknesses.

A broad span (figure 1) means that there is direct communications and interactions between the manager and their many reports (i.e. people who report to them.)

The benefits of this are that everyone deals with the same manager, and as a result everyone is more likely to be aligned with the manager’s vision of what should be done.  The disadvantages are the cost to the manager in terms of time to deal with each staff member.

A tall span (figure 2) means that there are more layers of management between the frontline and the top level management, and as a result there is the opportunity for the vision and communications from the top to be muddied by misinterpretation. The benefits of this model are that the managers all have more time to spend on each person and the work at hand.

Naturally a balance between vertical and horizontal spans has to be found for each organisation, and of course the balance changes within organisations, depending on a number of things such as the complexity of the work, the worker’s self sufficiency and the culture of the organisation.

A couple of examples to illustrate this point;

  1. Production line workers typically work in a large worker to manager ratio (say 25:1) as the work is low in complexity and the worker is basically self sufficient.

  2. Call centre workers also have a reasonably large number of workers to managers, but this varies depending on the complexity of the role. Simple mass market enquiries (e.g. paying a phone bill) might have staff to manager ratios of 25 or more to 1, whereas complex business to business transactions may be supported by smaller teams with say 10:1 staff to manager ratios.

  3. And a bunch of high end business consultants might work in a team of 4 per manager because their work is highly complex.

So, what does this mean for project teams?

There are multiple lessons to be drawn from this concept. And they can be categorised into

  • Organising project teams, 

  • Identifying and managing stakeholders and 

  • Designing future modes of operations for clients. 

And there is potentially some lessons that can be learned for managing requirements.

More to come, but first; Your thoughts on this topic?

3 July 2008

BABOK 2 presentation by Kevin Brennan

This presentation is from Kevin Brennan, the IIBA's keymaster to their BABOK.
It's a preview of what will be coming out in the BABOK version 2, later this year.

1 July 2008

Some posts on Project Sponsors

I wanted to write about the role of the project sponsor, but found three good blog posts that start the discussion for me. Have a read;

 We'll come back to these points again in the near future.

Photo by Melbourne Puppetry 

care of CC and Flickr