Search This Blog

28 January 2008

Reminder: Carnival of Business Analysts

A last call for submissions to edition #6 of the carnival of Business Analysts.

If you have a post you would like to contribute please let me know either via the comments, by emailing me, or by the carnival submission form.

This month's theme is Requirements Communication.

27 January 2008

Becoming a Software Testing Expert

Want to learn more about software testing? This presentation goes for an hour and is designed to provoke your own thinking.

It's angle is on building your career through evelvating your performance. (And you do that by addresing outcomes rather than process.)

Even if you are not a software tester, you can learn from this in two ways; what are the testers doing, and are they doing it well? And what career building skills can you adopt to your own profession?

You tell me whether it works for you or not.

26 January 2008

Project Estimating

Research and practical experience suggests that estimating is one of the key opportunities for projects to set themselves up to fail.

Basically you ask the team to take an educated guess how much effort, time and money it will take to tackle this new, unique, ill defined problem. Or you make a less educated guess yourself. You are then held to that estimate by the sponsor and accounting people.

When down the track your estimate was too low your bullish attitude is seen as incompetence. You failed to meet your self defined targets. And if you come in below estimates you get a reputation as a budget padder.

The traditional approach to this issue in the corporate project world has been to spend months estimating and re-estimating until most of the uncertainty has been cut away.

Fortunately there are resources around to help you. Mike at Leading answers has posted an excellent article on Estimating Best Practices.

Recently I discoverred the webiste for a product called Planix which says it calculates estimates based upon a bunch of things like use cases, and so on whichthen calculates function points and a bunch of other mysterious things to come up with time estimates.

I like the idea. Has anyone tried it or a similar product out?

Note to self; Pam Morris of Total Metrics is referred to regularly when talking about function point in Melbourne Circles.

24 January 2008

Requirements maturity

An article by Nilesh Raje has been published at the IIBA website which asks “Who Defines Requirements?” This brief article touches on the iterative nature of defining requirements and settles upon the premise that the earlier you baseline requirements the better the project will run.

Nilesh’s article is probably a bit too brief to add a lot of value to many practicing business analysts but it does start you thinking about the topic. We know, for example, that requirements are good.

In fact, effective requirements definition and management are important. The oft quoted Standish CHAOS report identified at on e point that 40-60% of project failures can be related back to poor requirements.

We want to know more. So, let me ask the Requirements Question a different way:

What is the journey that requirements take through the project lifecycle?

Who articulates them, in what format, where and when in the project lifecycle and environment? And while I am at it, how are they identified, and validated, who uses them and how are they communicated?

There is a requirements management maturity model written down and it deals with the increasing levels of formality and sophistication in eliciting and managing requirements. As usual the model comes in five levels.
  • Chaos
  • Written requirements
  • Organised
  • Structured
  • Integrated
You can read more about this maturity model here.

Depending on an organisation’s maturity in dealing with requirements they journey will be different and as projects mature often the documentation catches up. For example, at the very earliest stages of a project it may be a few ideas or a diagram jotted down on scrap paper. These high level concepts may end up in a 150 page requirements tome.

At what point do you think requirements evolve from broad statements in a project scope document (or brief) to real tangible things that need to be identified in use cases or written into a requirements specification?

Bas De Baar > Project Sociology

Bas de Baar runs a website and blog at He has also written two books called “Surprise! Now you're a Software Project Manager” and “The Microwave way to Software Project Management.”

Bas’s particular angle on Project Management is that more attention needs to be spent on managing the people. I have been reading his blog for a while and occasionally commenting on it, and yes, I recommend it to project managers and people who work on projects in general. In particular Bas reads widely and often points his readers at some fascinating information on project management.

Recently the topic of social project came up again. I referenced it here. The blog post and presentation got me more curious about the topic. In particular, as I read the presentation I disagreed with several of the premises, but not with the conclusions. It prompted me to raise a question with Bas.

My thoughts went like this: If traditional gated project management is one end of the project methods spectrum and Agile is the other, where does project sociology fit in? From what I can gather, I think it applies across the spectrum of methods and practices.

Sociology is about the tensions and challenges that come with bringing diverse people together in a social environment. This applies regardless of the project methodology, and in my view is important in all work/project environments.

Bas has a Master’s degree in project management and so is well educated in the higher level theories. In his writing it appears that his views on methods is that they are tools to be pulled out and used as the situation demands it.

So I asked Bas, where he sees Project Sociology fitting in to that spectrum, and why is it he seems to becoming an agile enthusiast?

He agrees that project sociology is not specific to any particular method, and goes further to say that project sociology (and psychology) is in fact “the only way to understand why projects are taking a certain direction; why things happen or don't happen within a project”

As for his vies on Agile software development, his view is that the philosophies underpinning Agile are aligned with his BUT projects are all unique and have their special sets of needs, and this context needs to be understood.

However, the Agile way has the advantage of explicitly addressing the human aspects of project management and adapting to change.

At the end of the day projects need to be focused on solving clients’ problems, flexible and oriented towards outcomes rather than ceremony. Again these are things that are articulated in the Agile Manifesto.

Lastly, what was it that got Bas motivated to spread the word about the Social Project Management presentation? It was “the link between agile (the underlying assumptions), the fact that they seem to work for a certain type of projects, and tells us the next big challenge: do they scale?”

You can read more about BAS’ views on Agile here and here.

You can read his 15 minute presentation on his Surprise book here. And you can buy his book for a light and entertaining read here.

2007 Best Practices in Change Management

Prosci, the organisation that run the website and the people who publish the ADKAR change management framework. They recently published the results of an international survey into organisational change management.

426 people from 59 countries participated and the result gives an international cross industry view of what is going on with the change management aspect of projects.

A couple of key things from the report;
  • In general more time and money is being allocated to change management
  • Practitioners usually feel like they didn’t plan enough, and if they could go back in time would spend more effort here
  • The support of the sponsor continues to be a critical factor
There is more. You can read the executive summary at their website here.

If you would like a deeper discussion on the contents you can contact the Prosci consultants via their website.

Alternately you can contact me to discuss the full contents of the report and what issues your organisation or project faces via the email link on the right hand side of this page.

23 January 2008

What do you think a business analyst does?

I have posted something at IT toolbox on the topic of the Business Analyst role. The blog post identifies the diversity of the BA role and asks readers to share what BAs do at their organsiations.

Depending on the responses I'll write something about it here. In the meantime if you want to participate in the dicussion head on over.
(You'll need to sign in to comment.)

22 January 2008

Career advice; Mix your skills

I asked my friend Nathan to donate a short article to the Business Analyst Handbook. He generously donated the below.

Nathan is midway through a successful career that has included consulting, a tech start-up, and now is involved in greening the world through encouraging investments in sustainable and green businesses. In amongst it all he has worked on several tech and no-tech projects as an analyst.

Mix Your Skills

While it is easy for BA's to rely on process, IT or systems skills to get a gig, to advance your career it is important to add to your skills tool bag.

Skills that make most sense are often included in the umbrella term - 'project management skills', but what does this mean?

Key facets of project management skills might include, budgeting and financial management knowledge, communication and media management, people management and that often overlooked skill - the ability to write concise and clear management reports - for all important project sign-off's.

Starting with reporting - if you have never prepared a report for a board or a senior management team, find someone who has and see how one is written. There is an art to clarifying your messages and getting people to agree with you. And don't assume that high level summaries get the job done. It is important to carefully analyse the outcomes you are after and tell your senior reports exactly what you want them to do.

On financial skills there are two observations I'd make.

  1. Get comfortable with budget spreadsheets, P&L statements and Balance sheets. Not because you'll use them all daily, but because they'll help you to think about financial management in a structured way. And most importantly
  2. Treat the project budget like it is your money. The boss will take you seriously on managing a budget when he or she doesn't have to worry that you'll blow theirs.

On communication and media, don't underestimate the specific skills involved here. Clearly identifying stakeholders, the issues you'll need to manage with them and the way your program will be perceived within your organisation and externally are essential project management skills.

If your program has some community impact and may hit the papers, then the importance of these skills is greater. Get some help if you need it.

From Business Analysts Handbook

21 January 2008

Prince Lite > Let the Dog Wag its Own Tail

A guest post from Dr Peter Merrick of;

It is not news that a lot of money is wasted in IT projects. What is surprising is how senior managers take a complacent attitude to IT project failure; that is until the project is 9 months late and consuming money hand over fist, with little evidence that it is ever going to be finished.

In my experience the problem is not with technology. Let me dispel a myth; the user requirements will not become clear as the project goes along. If you are a business stakeholder who needs IT to stay competitive, it is no use delegating the details to your supplier. You have a part to play, and if you do not play that part then the project will fail. Depending on the amount of money involved, this will cost someone their job.

Let me be controversial. It is in the interests of the supplier NOT to work from a clear simple unambiguous statement of requirements, because where there is no specification, there is no definition of success or failure so how are you going to judge it? By the time you run out of patience, the bill will have soared.

Sure, databases and OO modelling is a specialist subject, but anybody can understand use case models, activity models and screen mockups and that is all business people need to understand to play their part because UML (the Unified Modelling Language) takes care of the rest. Technies know how to transform these ‘business oriented artifacts’ into code. The other great thing about this approach is the user acceptance tests are described upfront. Progress can be measured. Success is defined.

The technical community puts a lot of store in project management frameworks, like Prince2 or RUP, but these approaches are flawed because it is not project ‘management’ that is of interest, rather it is project ‘delivery’. The fact a project is well managed and that it ticked all the boxes, does not mean it will deliver a working system.

What is needed is a delivery framework that priorities the business community stakeholders; the senior management, the middle management, the project management and the users. That means producing artifacts that the business community can fully understand and own intellectually by making the fullest use of pictures and ensuring words are kept to a minimum and that the documents overall are short.

If they are not short, they will not be read, defeating the purpose. Furthermore, the gap between the business stakeholders and the technical stakeholders must be bridged by the business requirements specification which must provide a completely unambiguous statement of requirements.

My response to the problem of bloated frameworks is to define PrinceLite; a process designed to let the dog wag its own tail, by which I mean really put the customer back in the IT project driving seat.

The main points of this new framework is it explicitly recognises the needs of all management stakeholders, it defines artifacts that are easy to understand, yet is based on UML so they can be transformed into solutions, and it comes with downloads of worked examples

Dr Peter Merrick holds a Ph.D from UEA in Software Engineering and has published on the subject of UML. He has worked for the Health and Safety Executive, HMRC, Great Hotel, University of Cambridge Examinations Syndicate and the European Patent Office. He currently holds a senior contract position with central government and is available to discuss any of the points he makes here or on the PrinceLite site.

20 January 2008

Change Request template

Better Projects Templates
I am uploading a couple of project document templates to Google Docs. As I add more I'll post them up here. You are free to use them for any purpose, but as a courtesy would you please reference this site as your source.
The first document is a Change Request form.

[edit: I have now added a page with a range of templates including Change Request, PMP, Quality Plan,  Communications Plan, Requirements Management Plan, and more.  See them here.]

19 January 2008

PM Methods in context (of Perrow's model)

Recent conversations about project management methods called to mind Perrow's technology model. Technology needs to be appropriate to the degree of complexity inherent on the problem you are facing and the maturity of the subject area domain.

I wonder if this placement of project styles fits the model? Readers, what do you think? Does this work or not?


18 January 2008

Requirements Analysis

This topic doesn’t get spoken about too often. And in the recent Carnival of Business Analysts I published I felt that the actual step of analysing the requirements for value and thus for importance wasn’t well addressed. So I looked further afield and came up with this information.

In a Master’s thesis (Rashid Awan 2005) I recently read “Requirements Analysis” was bundled with “requirements negotiation” which makes sense. Rashid Awan explains these ideas as the process of determining what is and isn’t in the scope of the technical solution.

How do you know what requirements are most important?

What will rarely work is asking people which requirements are most important. A common answer is that they are all important, otherwise they wouldn’t be requirements. This view makes sense and often sensible and mature stakeholder have already demonstrated discipline by not bundling in any unnecessary requirements.

What follows is a brief discussion on some requirements analysis techniques. I expect it will be useful for new analysts, and that more experienced analysts may pick up one out two new ideas they can try out.

If you have a particular technique you would like to share, leave a comment or send me an email and I’ll add it to this post.

Mandatory and Optional

Many analysts categorise requirements as mandatory or optional. Typically without the mandatory requirements fulfilled the solution simply won’t work. The optional requirements tend to be about optimising the solution, and are often related to customer or user experience.


Ranking is a useful tool when only limited resources are available. Ranking requirements is core to Agile development which is a resource and time constrained mode of development. If we only have 2 weeks to build the next iteration what are the most important things to develop.

Value Analysis

Which requirements contribute the greatest part of the value? The challenge with this approach is that it is often hard to isolate requirements and link them to specific value. It can often be done with effort but, as an example, how do you attribute a value to rules on passwords and how do you manage to determine that value on tight timeframes?

Requirements Risk Analysis

Last week I wrote an article on Requirements Risk Analysis for Modern Analyst. Some of the ideas in the article included identifying requirements that introduced risk to the project and thinking whether you should drop them as a way of avoiding the risk. Modifications and mitigations are also discussed as ways to manage requirements risk.

Kano Analysis

I like this model and have written about it before. It’s about identifying what is going to delight a customer if delivered, and what is going to leave them dissatisfied if not delivered. There are various hybrid approaches to this model that make it simpler to deploy that the original model.

Basically ask you customers to rate requirements on Likert scale on two metrics; how much they like the requirement and how much they would be unhappy if it were omitted. You then plug them into the model and get insight into how the requirements are going to affect your client’s perceptions of success.

Stakeholder impact analysis

Stakeholders have an enormous affect on whether projects are seen as successful or not. Different stakeholders have different views on what is important. If you take the time to understand who cares about which requirements and how they influence the end view of project effectiveness you can play to the right preferences.

(This is the reason why user interfaces for back office systems are often sacrificed; back-office process workers are paid to turn up and work with the systems they have, and typically don’t complain much about systems as long as the appropriate change management activities are used.)

PERT Analysis

In more complex projects where there are several components, or in projects which are built iteratively you need to sequence solution components in a particular order to accommodate functional dependencies.

Sometimes it’s other issues that cause work to be scheduled in a particular way (eg resource availability.) Sequencing means some things up front and some things at the back. And some things are not done at all. (Read more about PERT here.)


Analysis leads to understanding what is most important and what can be left out of the solution. It also gives insight into the order things should be developed and the architecture of the solution.

Requirements analysis is a topic that does not have enough written about it. Take this as an opportunity to write about your favourite techniques, tips and insights. (And link to your article from the comments here.)

17 January 2008

Raven's Brain > Insights on Agile

A new feature of this blog for 2008 is going to be more interaction with other bloggers.

Today I read a post at Raven's Brain espousing the greatness of Agile and I was wound up enough to rant in her comments. It is partly replicated below.

I actually recommend the blog to all people interested in project management. It has consitent quality posts and is worth reading and even subscribing. I have included it in my regular list of reads and it is in this blog's blogroll.

Anyway, part of my rant is below. Go to the original post to see the context here.

Raven quotes Steve McConnell:

"...they utterly fail to acknowledge the inherent uncertainty and variation that cannot be removed by "up front" attempts at perfectly stable project plans and/or product requirements..."

Really, in my experience (mainly PMI or Prince2 formal project management environments) I have rarely, if ever, seen a project be so rigid that it can't allow for change.

This whole Agile is the way to manage uncerainty and change is beginning to get my goat. Agile may have strengths, but so do other styles of pm, and they all address the need to manage uncertainty and to accomodate change explicity.

If you are turing to agile because of this particular reason, it's not because the traditional methods are flawed. It's because you are have weaknesses that can be managed more simply by some skills development.

So there you go. One of my views on Agile.

Business Analyst BOKs

Did you know that there are several documents that are described as Bodies of Knowledge that business analysts should be aware of.

In alphabetical order:
  • BABOK - Business Analysts Body of Knowledge, by the IIBA
  • G2SEBoK - Guide to the Systems Engineering Body of Knowledge, by INCOSE
  • NPDBOK - New Product Developmet Body of Knowledge, by NPD Solutions
  • SWEBOK - Software Engineer's Body of Knowledge, by IEEE Computer Society
(Thanks Barbara for making me aware of the G2SE.)
And of course there are the Project Management BOKs which have a wider profile, especially the PMI one.
Lastly Kerber has offerred up a draft version of an Enterprise Architecture BOK.
He has also asked the very good question "How do we keep up with all this knowledge?" Apart from being a blogging and project geek, are there any suggestions out there?

Update 17 Jan 09:  Loretta Smith writes an article for ModernAnalyst on the DMBOK - the Data Modelling Body of Knowledge.

Picture originally publised hereby Rafael Lopes

16 January 2008

A new domain name

Some news on the site: I bought the domain name

Look at the address bar and you should see it there right now. If you have the site bokmarked you might like to change it.

Cheers, Craig

Remember to be creative

And while we are on the topic of the importance of people take a moment to watch this advertisement. (Forget the product.)

15 January 2008

Requirements Traceability

Requirements traceability is an important part of requirements management.

It’s not a particularly glamorous part of the job, but it is crucial to complex projects in particular and good for all types of projects. Traceability helps you track what is happening to the project requirements, how and where they are addressed by solution and it helps manage those requirements that are not going to be fulfilled.

If you have ever been involved in project remediation then you’ll use the Traceability matrix as your first point of auditing what has gone before. And usually you’ll discover that little or no traceability has been done, which drives up risk and remediation costs further as more time and effort is invested to understand the relationship between requirements, business need and the solution design.

Even when you are not intervening, but are simply managing your own project you are less likely to discover surpirses such as omitted or mis-interpreted requirements if you employ this tool.

I don’t need to go into detail on the topic of how to perform Requirements Traceability here as there are two great sites on the topic I can refer you to;

Requirements traceability is a very important aspect of quality management for projects. If you are a PM you should make sure one of your senior team members is assigned to the task and make sure it is reviewed by the whole project team at each major phase of the project. If you are a BA you should know the contents intimately and use it to anticipate issues and risks coming up, and to manage the expectations and behaviours of both stakeholders and the development team.

14 January 2008

Social Project Management

Bas de Baar points us to a presentation on Social Project Management. Leisa Reiche presents her ideas on a new philosophy on project management with the focus on people.

Big picture; projects are run by people and more attention needs to be paid to them in order to deliver effective projects.

Leisa’s views are that this is a new approach to project management and is a shift away from large scale Gantt chart driven projects. This is where I disagree. No matter how large, small, traditional or innovative a project is it is always important to pay attention to the people.

Take a look at the presentation and if you have views maybe you’ll share them with us.

11 January 2008

Here comes 2008

2007 was a big year for this blog. I actually started it in 2005, but it was the beginning of this year that it became a bona-fide blog on projects.

Business analysis became a stronger and stronger part of the mix as the year went on. I became a PM via the BA role and I have some strong views on how important the role is for the success of projects. Naturally it is part of how I view project management and effective project delivery. I am not alone and the people at the IIBA and other organisations have put in a great deal of effort in sharing knowledge and expertise so that the role can evolve into a profession.

In 2008 this site will continue to explore and discuss the role of the business analyst, with a focus on the keys to effectiveness. I will also continue to share what I learn about project management. (Just because the degree is over doesn’t mean we stop learning.) The focus of the project management content will follow the same theme of looking at the issues that contribute to or hamper effectiveness.

I have also started writing regularly at a number of other sites. This will continue to be the home of my writings, but I will be trying to keep each article unique and specific to the audience of the particular site I have written for. I’ll post links from this site to those articles.

As for the content of this site; I have some ideas about site redesign and about a more structured approach to content. I’ll see how I go, but one of the joys of blogging is that you are firing off short roughly thought out ideas rather than following a particular format. It’s akin to cooking without a menu. It is easier and basically it takes less time that a more planned approach.

This is a PM site though…

In case you are interested; I published 180 items in 2007 and have something around 80 email subscribers. I doubt I’ll maintain the same pace this year. But don’t be surprised if it does end up at that volume. Blogging is addictive and sometimes I just get carried away. (If you are a regular reader and don’t like being bombarded by daily updates I recommend subscribing to the weekly update via Feedblitz.)

2008 is shaping up to be another busy year. Let’s see what we can learn about delivering good projects together.

7 January 2008

10 steps of PM career progression

(Still on holidays) I discoverred this care of Josh Nankivel's PM Sudent site. It's 2 minutes long and has some interesting insight.

1 January 2008

Requirements risk management

I am still on holidays, but here is someting you chilled northern hemisphere people might be interested in.

Adrian Marchis has posted an article I wrote a few months ago for Modern Analyst on Requirements Risk Management.

The high level concept is bringing the principles project risk management to requirements management.

Take a look (here) and if you are interested in commenting I am interested in hearing your thoughts.