31 March 2008

Reader Survey #1 Results

Over the last month I have had a poll in the right hand column of this blog. It asked who was reading us. The responses are below.



I was pretty happy with the response rate. Thanks to all our regular readers who participated.


Project Managers 63 (41%)

Business Analyst 61 (39%)

Quality/Testing 10 (6%)

Solutions Team 14 (9%)

Sponsor/Stakeholder 5 (3%)



So what does this tell us? I guess it highlights the fact that the main audience for this blog is project managers and business analysts in about equal portions.



Looking back over the last 2 months posts, this matches what we are posting about; an approximately even spread of PM and BA specific content, plus some generic project posts that are for everyone on the team.



It’s good to see some testers and solutions team people here. You are either looking to learn about the PM and BA role for when you take on the next role, or you are looking to info so you can work better with PMs and BAs. Either way, thanks for coming and participating.



We also had a handful of Sponsor/Stakeholder types. It’s always nice to have ‘the business’ drop in. You are welcome here anytime.



The more you inform yourself of how and why projects are the way they are the better you can arm yourself against project disasters. Projects are very different from operations in many ways.



If you ‘business’ folk would like to explore any particular issues you are welcome to ask. We’d love to help bridge the gap between these two very different work cultures.



We also encourage you all to refer your friends and colleagues in ‘the business’ to this site in the hope we can foster better understanding of some of the many project issues we all face, and thus help more project hot their targets.



Thanks all for reading and for participating in the survey.










Image from http://www.freephoto.com/

28 March 2008

Most Requirements are just Design Decisions

The language we use both reflects and influences our thinking.

The term “requirements” has its roots on bureaucratic thinking, that supposes a static and impersonal business world where specialists would be able to uncover, extract and document the definitive specifications for software systems.

Jeff Patton in his post
“Requirements considered harmful” alerts us that most requirements are just design decisions. He shows how typical behaviours like asking and giving requirements can be dysfunctional because they justify avoiding responsibility and stop collaboration on a critical success factor for software development projects.

Recognizing that most requirements are just design decisions, gives us a better chance to design and deliver more effective software solutions if we (a) carefully treat them as design products and (b) are ready to adapt them quickly to new circumstances.

Carefully defining requirements as a product of a design process means we should (1) use a collaborative process involving all relevant stakeholders, (2) reflect about the requirements under different perspectives: market, business, users, system and (3) use the most adequate tools and language to express the requirements in a common framework comprehensible to everybody in the team.

Being ready to adapt the requirements means being agile to sense and respond to relevant environmental changes and being open to incorporate new knowledge generated by the organization. The capability to learn and innovate, quickly adapting and creating changes is critical for leadership in the marketplace. Business software should enable these changes and not prevent them.

I know there are situations where requirement changes are beyond our sphere of power and influence. However, as responsible professionals, we should not just let requirement decisions hide under processes, documents and signatures. It is healthy to foster reflection on the what and why of software requirements. As Business Analysts, we should lead this process and help our organizations expand their possibilities.





Picture by Lindsey Lissau.
Original at Flickr

What if our whole world view of project management is wrong?

“We do not talk about what we see; we see only what we can talk about.”


This paper examines the way we have framed our conception of project management and challenges it suggesting that project management knowledge isn’t that special at all, and by building up this mystique around it we are hampering the ability of projects to successfully deliver results rather than helping.

It’s an interesting perspective, and one that helps you think differently about your job and the work you do. It makes you challenge your assumptions and look to find better ways of managing and delivering projects.

The question it raises for me is how much is project management knowledge constructed to solve real problems, and how much of it is self-repeating, self-sustaining behaviours that act mainly as a way for PM professionals to establish and maintain their importance in their professional community.

(The same questions can be applied to the establishment of the IIBA and the BABOK.)

If you are philosophically inclined this article is for you.



Reference: Stephen Jonathan Whitty (2005) “A Memetic Paradigm of Project Management” International Journal of Project Management (2005) 23 (8): 575-583. Retrieved from http://espace.library.uq.edu.au/eserv/UQ:8801/sjw_ijpm_05.pdf

Picture by Camilla Hoel.
Original at Flickr

27 March 2008

On Bureaucracy versus governance; managing the balance

My proposition today is that generally bureaucracy gets out of hand as soon as you stop trying to keep a lid on it. And it is a barrier to change. That means that you have to fight it to get things done.

When you are in the projects business you are in the business of getting things done. You are not part of the normal business landscape; in fact you are there to disrupt normal business by introducing new products, tools or processes.

Bureaucracy is your enemy.

But bureaucracy is how many larger enterprises apply governance to project management. Senior managers and executives are busy with 50 or more things at any given day and your project only gets 30 minutes of their attention a week, or possibly only a month.

They have hired in systems thinkers to help ensure that you and your project team are following the right processes and ticking the right boxes on the way to project delivery. And they use those systems to fulfil obligations they have to their superiors.

Of course this can get expensive; especially in large complex organisations where everybody has a stake in your project.

How do you manage bureaucracy (and costs) down but still comply with governance requirements?

The answer found is through taking the time to understand the true governance requirements and managing ‘just enough’ reporting and governance activities to keep everybody happy.

Examples of this include
  • Creating lists rather than long descriptive documents,
  • Shortening the documents you write and investing the extra time you may have set on the document on talking with stakeholders and the project team,
  • Reducing the frequency of reports, or even changing the communications mode from push to pull (that’s putting project reports up on an intranet,)
  • And customising your reports so they are in the most useful form possible for your audience always helps smooth things along.
I bet you readers can think of many more examples.

This in no way reduces the need to communicate to all the stakeholders, users, team members and suppliers on projects. Communication is important. But this is about making space in your week to communicate by taking a smart approach to the bureaucracy.

25 March 2008

The 3 levels of requirements

Traditionally people talk about three levels of requirements.

You can think of it as a sort of heirarchy descending from the strategic goals of the organisation to the physical implementation of tools and processes.
  • Business Requiremets
  • Functional Requirements
  • System Requirements

Here is a concise article explaining the concept. Note it adds a fourth level to the front - market drivers for change. This article describes the four levels of requirements, gives a view on who should 'own' each level and how they are usually modelled or documented - "The Requirements Hierarchy" Posted April 30, 2007 by John Mansour

And here is a similar article with a slightly different view at Search Software Quality; What Are Requirement Types Jan 01, 2008 by Roxanne Miller.

And there is my post on this topic from a week or two ago.

Lastly, don't forget non-functional specifications. Often a neglected area, this is where many projects have trouble delivering.

24 March 2008

Survey - Last days

It's the last few days to fill in our "Who are you?" survey on the right hand side of this blog.

Thanks to all who have filled it in so far!

21 March 2008

More on Solution Assessment and Validation (A post script to the Carnival of Business Analysts #7)

I felt that the last edition of the Carnival of Business Analysts missed the mark a little. Here is some extra information I want to add to the Carnival of Business Analysts #7: Solution Assessment and Validation.

For a start you can get to the IIBA’s BABOK from here. Chapter 7 addresses Solution assessment and validation. Read the chapter sub-headings and you’ll see topics such as Developing alternate solutions, evaluating technology solutions, useability, quality assurance, and implementation.

Having read a draft of the Enterprise Analysis chapter of v2.0 I think some of this content may move into the EA chapter, but we aren’t there yet so we’ll take a quick look at them all here.

Developing alternate solutions
When coming up with a solution you should typically look at more than one approach.

Many projects come up with the deluxe, budget and middle road proposals to contrast the strengths and weaknesses of different approaches, but there are more options available to you also; for example build, buy or buy and customise. Another dimension is do you enhance the existing infrastructure or do you build on a new platform? See some case studies on this topic at Chief Architect.)

There are many ways of approaching solutions and each one of them will address the project goals to varying degrees and have particular impacts on the organisation. Your jobs as the project BA is to assess these solution in terms of how well they’ll meet the business requirements. One tool you may use is a requirements traceability matrix. Another is validation by business stakeholders, for example by demoing a prototype. And there are more including Alpha Testing, Field Testing and Market testing.

Evaluating technology
A Traditional and process heavy approach to selecting and developing a solution idea goes like this;

That represents a traditional waterfall approach. In these modern freewheeling times, solutions may not follow this process, stages may overlap, or the process may be fast tracked, bundling two or more phases together. Anything goes these days. Regardless of the development approach each stage that is applied needs to be assessed and validated.

Is this solution the best one for the business? Does it find the right balance between cost, time and quality? Does it align to strategy and standards? Does it address the project goals? You are the judge.

Useability
Personally I am no expert but I know what I like.

I have some views that are supported by others including that UI for applications used by back-office people don’t need special attention; they get paid to come to work and will learn the system regardless of the UI. Of course there are some issues with training and ramping up to expert users, but these are more relevant to the tools presented to sales staff and customers.

Other people disagree with this view, so you'll need to form your own opinion.

Another thing I think is that you should do some sort of task analysis to work out how to lay out features in relation to each other, but there is a whole world of UI stuff out there and I say go and explore that if it’s your thing.

One thing we all agree is that you can’t leave user interfaces, and especially design to programmers. At least not usually: but there are always exceptions.

Quality Assurance
The QA work that a BA may undertake, or participate in, includes developing a test strategy, a test plan, and test cases. A BA may also procure and manage users for UAT, or participate in it themselves. During this phase a BA may have to find workaround for system shortcomings and communicate what’s going on to various stakeholders.

Of course one of the main things with testing is that the test cases are mapped back to the requirements statements, and for testing to be easy he requirements have to be written in a way that they are testable. Requirements statements like “The UI must be easy to use” don’t make for easy test cases. What does easy to use mean? Instead try for statements that can be tested; e.g. “The UI will be brand compliant.”

Another thing to remember is that BA's are not professional testers, and as such we can learn from others. Don't just jump in. Prepare yourself.

Implementation
There are two aspects to implementation; the physical deployment of new systems to IT infrastructure and the deployment of new processes, rules and behaviours to the business environment. Depending on the role of the BA they may be arranging or participating in on, the other, or both.

Some techniques to help you through the business side stage of the project include Business transition plans, a review of your stakeholder impact matrix, change management plans, and changes to business process, policy and rules.
Change management is a big topic and could easiliy be expanded into another post, or even series of posts. Or even a blog of it's own.

(I’ll keep adding links to each topic for a few days. Put up a link in the comments if you know a good one.)


3 ways to be a better BA

I posted an article at Modern Analyst asking BAs to thing about three ways to increase their professional skills and knowledge.

Start blogging, participate in online and realworld coimmunity events, and find someone to coach or mentor.

I also invited these people to link back to this post so I can refer my readers to the new blogs as they appear.

You know this is a numbers game. The stats are something like 5% will try it and only a small fraction of those will stick with it. These are those 1 in 20 people that you meet at work and just stand out as excellent professional and enoyable people to work with (regardless of their professional experience and skill level.)

So. Let's see what happens.

(The Moden Analyst article is here.)

20 March 2008

Carnival of Business Analysts # 7; Solution Assessment and Validation.




Welcome to the March 10, 2008 edition of the Carnival of Business Analysts.

The Carnival of Business Analysts is a blog carnival about Business Analysis. What does that mean? It means each month we ask readers to submit blog posts about a particular BA related theme*. We flesh that out with our own search for blog posts on topic.



Previously in the Carnival of Business Analysts we have investigated several of the knowledge areas described in the BABOK (v1.6)
This month I have divided the articles into two sections; on topic and near misses.

1. On Solution Assessment and Validation

Brad at Seilevel’s Requiremets Defined Blog has two posts discussing the difference between validation and verification. Part 1 is here and part 2 is here. Part 1 gives a definition and part 2 gives some useful techniques.

Techie
at Quality Assurance and Software testing also has a view on The Difference between Validation and Verification.

Bas de Baar at SoftwareProjects.org goes further with practical tips. He talks about how pilots and prototypes go a long way towards validation and verifying solution approaches in Benchmark and Prototype. He’s also got this nice riff on how documents don’t work independently of other communication. This article is part of a series by Bas on requirements validation which starts here; Requirements Validation.

Adrian has posted an article by Scott Ambler at Modern Analyst on Requirements Modelling and Validation for Agile projects. (Free sign in required.)

There are a few other articles there by Scott which discuss requirements management for Agilistas in case you are interested.

Craig Borysowish at ITToolbox gives 3 tips for requirements documentation, with step three being a detailed description of verification and validation activities.

Josh Milane at MIT Technical writes about the Absurdity of MoSCoW requirements. He says a requirement is either a requirement or it ain’t, so why all this fuss over must have, could have, should have?

Guy Beauchamp also gives us a look at how he ensures requirements are aligned to project goals in his article The Fundamentals of Business Analysis, again at Modern Analyst. (By the way I have written about his concept diagram here at Better Projects.)


Addendum: I have added some more information in a new post here.

2. Almost on Solution Assessment and Validation

CMOE presents Strategic Planning for Small Businesses posted at Teamwork.

Woody Maxim presents The Answer posted at Woody Maxim.

Edith presents Three Golden Rule of Presentation by Guy Kawasaki posted at Edith Yeung.Com: Dream. Think. Act..

Noric Dilanchian presents Business model defined - Dilanchian Lawyers posted at Lightbulb, saying, "Here's the best definition we've ever come across of the term "business model". It comes from a book containing original academic research into business model issues at the Palo Alto Research Centre (PARC). PARC is arguably the greatest IT research centre of all time. The PARC riddle is - how did it succeed in invention and fail in IP and technology commercialisation? The takeaway is that carefully crafted business models build the bottom line."

Brian Terry presents Why you MUST become fanatical at testing and tracking posted at Big Selling Website Design.

Stephen Dean presents 3 Quick Ways To Judge Your New Product Idea posted at Stephen Dean's Copywriting And Internet Advertising Blog - Copywriter.

Warren Wong presents What Commiting To Something Means And Why You Should Do It posted at Personal Development for INTJs, saying, "Here are good reasons why you shouldn't be afraid of commitment."

Anna Farmery presents 10 Ways Brands Can Benefit from Joining the Conversation posted at The Engaging Brand.

Joshua C. Karlin presents Powerful Yet Reasonable Goals posted at Marketing & Fundraising Ideas.

Brian Terry presents The Law of Presentation posted at Big Selling Website Design.

Louise Manning presents Quality assurance or quality control posted at The Human Imprint.

The next edition will focus on the last of the BABOK knowledge areas Enterprise Analysis and will be published in late April. Get your (relevant) submissions in now!!!)

That concludes this edition. Submit your blog article to the next edition of the Carnival of Business Analysts using our carnival submission form. Past posts and future hosts can be found on our blog carnival index page.


* by the way readers and bloggers, the Blog Carnival tool is a great idea, but it attracts a million and one articles all claiming to show you the way to make a million dollars online with no effort, so if you use the Blog Carnival tool be warned there is a bit of spam filtering you have to do manually.


The separate roles of the PM and BA

Care of Kevin Brennan's blog I found another article talking about the differece between the PM and BA role and why on any reasonable sized project it is important to have the roles separated.

The role also expands on the idea of the IIBA and PMIs contributions to improved project performance. The basic idea is, as usual; skilled, experienced and qualified people go further that methodologies and tools in ensuring good results from projects.

No arguments here. Read the article here. (You have to log in.)

Photo was by Dunechaser at Flickr
(and is part of a series on Lego CEOs).

19 March 2008

Design/application architecture within Agile

As I said in my previous post, I have a couple of issues with Agile. In that article I spoke about measurement within Agile supporting EVM which I think is necessary for business decisions. The second issue, which I did not discuss, is design/architecture.

As some of you may know, I am a business analyst. However, I started out as a programmer and had the opportunity to work on several projects using Extreme Programming (XP) processes. I also worked as a developer/project manager for one of these XP projects.

Even when doing XP, we still felt it was best practice to go through a design phase that included a high level architecture of the product which we adhered to for the rest of the project.

When you are building something from scratch, you need to have an idea of the direction to go. Minimally you should have a general diagram outlining how the pieces of the product (e.g. key features) will fit together. So when our team was asked to implement an Agile development process where I work, I couldn’t help but ask the obvious question: "How will design fit into our process?" The scrum-master suggested that design was an outdated concept.

After doing a bit of research, I found that the community thinks that it is an iterative process where the project defines the size, formality, and timing of the design process. These processes all apply if you use the Agile Modeling Methodology (AMM).

I'm not sure how that relates to Scrum, but from my inexperienced vantage point it looks like Scrum is a way of managing development while AMM is a approach used to aid implementation. If any of you out there have some insight into their relationship, please post your thoughts and references in the comments.

Here's what I like about the AMM design/architecture concept: it is iterative and the overhead is only as much as makes sense. You do “just enough” up front to get moving on the project and then refine the architecture as you go. Thisarticle outlines a great general rule about when you need to do more or less design up front.

I love that the documentation of the design can be as simple as "a plain old whiteboard (POW) sketch" or a full fledged model, if necessary.

As I have learned more I have found that if someone tells you there is no design or architecture in Agile, you might want to question their motives for avoiding it. The true answer is, "There is only as much design up front as makes sense."

Agile is not an excuse to get out of doing the things that are needed for making business decisions like Earned Value Management (EVM). It is also not an excuse to get out of doing all of the up-front documentation. Cutting back is not cutting out.

For example, creating a more formal model that might help the Product Owner or external stakeholders understand the project better. Agile is a means to adjust the overhead of a project to be just what is needed and not more than that. In my book, that's the most sensible goal in the industry.



Planning Iterative Developments

This link takes you to a powerpoint presentaion by Annie Kerregan of Cardinal Solutions on project planning for iterative style projects.


There is some great content in here, and if you have run a few projects iteratively you'll know that they are much more likely to deliver results (and happy sponsors) the usual hard slog and heavy doc approaches.




This came via Josh, who runs a project management and requirements blog here.
Photo by splorp at Flickr

18 March 2008

Process Models Bridge The Requirements Gap

This is a review on a whitepaper that was sent to me by a friend;

The Requirements Communication Problem: Process Models Bridge The Requirements Gap by John Forrest of Holocentric. (Original article here)

This white paper proposes that linking requirements back to business processes is the first and best step you can take to ensure the quality of your project's business requirements.

There is another study I read a while ago that says processes lead to problematic requirements management and that (use) cases should be used in preference.

According to the wise folk who wrote that doctoral thesis business process models should only be used for non customer value adding work; typically back office support functions, or where you are automating the whole thing so the customer gets an instant end to end and seamless experience.

This aligns pretty nicely with management theory which suggests that if your front line people are dealing with complex or dynamic customer requirements they shouldn't be locked into processes; rather they should have tools that enable them to achieve desired outcomes.

(And this is where many localised process management teams and frontline management have got things so very wrong.)

Having said that, there is a lot going for mapping requirements back to frontline activities (and processes.) And business process management is still a growing field with plenty to offer in the right context.

Reading the article I felt there are a few incorrect points - e.g. managing requirements is not the MOST important aspect of project requirements. I checked out the business and they sell process mapping solutions. Naturally it's a bit biased.

Bottom line: The article is worth a read but be sceptical that processes are the solution to requirements management. They are just a part of the puzzle.

(You can read another review of this article at ZDnet here.)

17 March 2008

Stomin' Normin'


Forming > Storming > Norming > Performing > Adjourning


You might be familiar with this 50 year old view of how teams interact and develop (Tuckman 1965.)

How often do you consider the team development phases when running projects? Do you use the same team each time, or do new people join on each engagement? Are you the new person to established teams when you start each new project?

One of the many challenges project leaders face is getting the team to gel and work effectively together as quickly as possible. In the context of this model you want to get people to the ‘performing' stage as quickly as possible.

There are a couple of good options for you; team ‘off-sites’ are good. Get your team working together in social or creative activities to help work through the forming, storming and norming phases.

It will probably take more than one session, but there are a number of project specific activities that are perfect for taking your team on this journey.

Examples can include workshoping a team charter to help people get focused on what the project is here to achieve.

This will help foster a team identity and get the team to identify with each other as part of one organisation with a common purpose a scoping workshop to help people storm through the phase of determining who is who and how the relationships will settle once you are doing the hard yards Reviewing the initial project plan and working through the initial risk assessment workshops are also useful for normalising values and expectations.

Once the teams have been through these exercises together they know what each other are planning to do, and see how they fit into the bigger project picture. You also have the opportunity to identify gaps and work out how to manage them.

When you have worked through the storming and norming phases you’ll find the team is are working more cohesively and delivering their work more quickly and accurately – you are in the performing phase.

As the project winds down people will be leaving, and many won’t be there at the end. Take the time and care to keep in touch with everyone on the team and invest some effort and money on a farewell lunch or other social activity that enables the team to have a final farewell and to celebrate their successes. (On longer projects you might do this at the end of each major phase.)
Photo by T(z)W. Tomasz at Flickr

14 March 2008

User Interface design

A comment on user interface design.

Found care of Raven's site. Originally from StuffThatHappens.com. You know it. You live this stuff.



12 March 2008

Measuring the Cost Benefit of Agile

Currently at the office we are doing a pilot project using Agile development methods. For the most part, I think Agile is a great idea.

The concept of short iterations is a lot more sensible than trying to get everything done up front with the customer only involved at the start and the end of the process.

I could go into the reasons why, but there are many other resources that do that better than I could in this forum.

However, I have a couple of issues with Agile. The first is that too often people don't consider the larger business context of the development process.

Question: How do you justify a project to a bean counter?
Answer: With a measure of the cost vs. benefit.

Question: How do you quantify the cost of an Agile project?
Answer: Use something like AgileEVM

As the article referenced above states, Earned Value Management (EVM) is a well established and accurate measure of a project's cost performance. Anyone who has ever had to manage a budget knows that tracking the cost of a project is an important part of managing a project portfolio. This does not change if you use Agile development.

I have had to justify too many projects to the people with the money to ignore some form of EVM just because I am using a lightweight development methodology. In my experience measurement is a necessary piece of the overhead and that means implementing some form of tracking actual performance within your Agile process.

So the idea to take from this is that Agile should work within the larger business context, not separate from it. It should provide a useful measure for the people responsible for spending the money wisely (e.g. AgileEVM).

Next: Design/application architecture within Agile.

What is Enterprise Analysis?

According to version 1.6 of the BABOK, Enterprise Analysis is the strategic part of the project lifecycle. It includes;
  • developing strategic goals and a strategic plan to get there,
  • understanding and developing the business achitecture,
  • selecting the right solution approaches for projects and developing their business cases, and
  • initiating projects and making sure they deliver value to the sponsor

All of these things are strategic activities that bookend the project lifecycle.

Chapter 2 of the BABOK (v1.6) describes these activities in more detail and you should go check it out today. It’s a fascinating topic and I commend the IIBA for including it in the practitioners’ guide.



Picture originally from

Thoughts on The BA and the SDLC


5 March 2008

Where do you fit into the picture?

A little survey is running on the right hand of the site. It asks what role you play on projects. Help us understnad who is reading this site and fill it in. It takes two seconds.
Thanks!


4 March 2008

On Stakeholder Communication

I had an opportunity to listen to a webcast on Catalyze called Designing a Sure-fire Stakeholder Communication Strategy.

Barbara Carkenord discussed the importance of conducting Stakeholder Analysis and developing a Communication Plan in the Requirements Gathering process. Here are some take-aways that will be helpful in any requirements communication process.

A firm understanding of all stakeholders involved in a project is paramount to business analysis. While documenting such analysis may seem extraneous and perhaps impractical, the knowledge gained from doing so is invaluable.

Barbara highlighted 7 Golden Rules to abide by when coming up with a Stakeholder Communication Strategy:
  1. Identify the people
  2. Get to know them
  3. Engage them early and communicate often
  4. Identify potential problems
  5. Reduce problems with your communication plan
  6. Fit that knowledge into your business analysis work plan
  7. Review alignment to project goals and adjust as necessary
Stakeholder analysis includes determining:
  • The stakeholders (who)
  • Their role in the project (what)
  • Their characteristics (what)
  • Their availability (when)
  • Their location (where)
  • Their motivations (why)
In my recent dealings with the stakeholders on my project, I found this form of analysis highly insightful in determining what questions can be directed at a particular stakeholder, lessening the amount of time taken to elicit accurate requirements. In listening to and documenting every stakeholder's concerns and motivations, I was able to see potential roadblocks in the project early on. And subsequently, in working through these issues with my project manager earlier on, we were able to minimize the loss of time and resources in analyzing and communicating requirements with our clients and our developers.

It is important to review such documentation prior to meetings so as to recognize the strengths, weaknesses, opportunities and threats in discussing aspects of the project with a specific stakeholder. If the goal of stakeholder communication is to engender trust among all parties involved in a project, then knowing how each stakeholder is motivated and works allow the BA to have more success during requirements elicitation.

A simple MS Excel Workbook with separated with worksheets, each representing a project stakeholder is sufficient enough to capture details of every stakeholder. I have taken to answering the 'W' questions as listed above as a starting point, but also included more material, including any information that may help me understand the stakeholder or the project better.

Having documented such material, my PM and I were able to plan our meetings more effectively, knowing exactly WHO mattered in WHAT discussion and WHY, and WHAT strategy was best way to draw information out of them. I went further to derive WHAT forms of documentation each stakeholder would need in order to lessen the burden on my end when writing up documents for them.

With regards to this particular project I had, having Business Requirements Document supplemented with high-level business system use cases were appropriate for the business users and management. A User Requirements document was appropriate material for the developers, and a separate system configuration and installations document was also written up so that the client's IT administrative staff was provided the ideal level of information for them to carry out their job in maintaining our software on the client's side.

Not knowing these needs would have left me in a frenzy of documentation that had little purpose and direction to any stakeholder - Lots of pain but no gain.

Therefore, if effective requirements communication leads to more successful projects, then understanding the stakeholders in their entirety will certainly go a long way in improving our work and delivery.


Photo originally by Hugo and sourced from flickr here.


2 March 2008

PMBOK Fourth Edition open for review

PMI is asking for feedback on version 4 of the PMBOK. From what I have read it's an incremental change.

You can read and comment yourself at PMI.org.

At the very least you can pre-read the next version (in draft format) and see where things are heading for PMPs.

Comments are being accepted until 22 March 08.


tragedy of the commons and project management

What do the tragedy of the commons and project management have in common?

(Thanks Bas for tipping me off to the Tragedy concept.)

The tragedy of the commons is an idea that was articulated in 1968 by Garret Hardin in Science magazine. (My research is from Wikipedia, so check the facts yourself.) The idea is that people acting rationally will deplete common resources.

A quick example is pollution generated by cars. Everyone knows that the pollution is bad and wants cleaner air, but no one person can make a difference. As a result you logically choose to drive your car around to work, the shops and so on.

Hardin observes that commonly shared resources will naturally be depleted to the disadvantage of all unless controls are put in place. Controls can come in various formats including privatisation, co-operative management or control from a government.

So, how does this concept apply to projects teams?

The most common reflection of this concept seems to me to be organisation’s inclination to use up the goodwill of its staff.

Many staff are working on several projects at once, or are supporting several projects at once. Each project manager, business analyst or other project leader is constantly asking people to stretch themselves just a little bit further for their very important project.

The goodwill of staff is a finite resource, but each project manager is working to deliver on time and budget and to quality, and it’s in their interest to use up a bit of that goodwill to get the short term gains of the next deliverable on time. Bit by bit, project by project staff are burnt out, even without the mammoth death march project

Many organisations try to manage this by charging staff out at a nominal (or sometimes commercial) rate. Even with charge out models people are often asked for that little bit of extra effort.

What is the answer? How do you keep your project team healthy and maintain a good work/life balance?


The first step is to recognise if this is a problem at your workplace.

Then you need to look at solution options. There are probably several of them including implementing better project governance, often via a PMO, teaching people to say no when they need to, and better implementation of charging out (and time tracking.)

What can you do?
Realise where your project is in the organisation’s pecking order. Are lives at stake? Will it have shareholders jumping out of windows if there is a delay? Or are you just another move in the marketplace that may or may not pay off?

If your project isn’t urgent, let people know and don’t expect miracles.

Be honest and upfront with your stakeholders and tell them when schedules are at risk and why (ie you are not project #1.) Let the stakeholders deal with the priority and take some of the pressure of your workers.

Spare some of the goodwill commons for next time.


1 March 2008

On Business Intelligence projects

What is business intelligence?

Business intelligence is, frankly, a buzzword. It looks to me as if it simply follows on as the phase 2 or 3 from a series of semi complete data warehouse projects run a few years ago.

Maybe that view is a bit sceptical.

Let’s take a look at the definition of BI from some experts. The CSIRO is the Australian government’s leading scientific research organisation. It has a neat definition of BI on its website.

“Business Intelligence is a process for increasing the competitive advantage of a business by intelligent use of available data in decision making. This process is pictured below.

The five key stages of Business Intelligence are: Data Sourcing, Data Analysis, Situation Awareness, Risk Assessment and Decision Support.”

Breaking down these categories further (and also care of the CSIRO);

  • Data Sourcing
    Extracting electronic information from text documents, databases, images, media files and web pages.
  • Data Analysis
    Synthesising useful knowledge from collected data using data mining, text understanding and image analysis techniques.
  • Situation Awareness
    Linking the useful facts and inferences and filtering out irrelevant information.
  • Risk Assessment
    Identifying reasonable decisions or courses of action based on the expectation of risk and reward.
  • Decision support
    Employing semi-interactive software to identify good decisions and strategies.

As you can see each of these dimensions can sit on a spectrum of fully automated to fully manual.

I see BI as the processes that use the data stored in those warehouses that were otherwise sitting there idly except for DM (let’s be honest: junk mail) campaigns.

How do I plan for a Business Intelligence project?

So, with BI flavour of the month, there is a reasonable chance that one or two of you out there are going to work on one this year. What sort of things should you know about BI projects to make sure you can do a good job?

I think there are a few key issues that, if managed, will make your BI project a standout.

Make sure that you don’t just focus on technology.

Enterprise projects often promise fully automated bells and whistles prior to business case, but once the project has been given the go ahead non-essential features start getting cut.

So, face facts: when you get rolling there are going to be substantial manual processes to pull data together, analyse it, apply context and then do something about it.

That’s right; people will be doing the machine’s work. So make sure you get them on board and engaged with your project.

The key question for you to ask your people who will be doing the work is WIIFM? (What’s in it for me?) Why should they take on extra or different work from what they are doing today? You need to explain the advantages of your new system to them and the enterprise.

It’s the same old human change management work that dogs all sorts of projects. It just seems that BI projects are even more likely to forget this aspect than usual.

What do business requirements look like in a Business Intelligence project?

Recently I posted something about a three level hierarchy of requirements.
1. Business Requirements
2. User Requirements
3. System Requirements

Take time on the first and second levels to understand them.

Too often on BI projects people jump straight into the data and relationships. Instead, ask yourself why this BI matters to the organisation? How will it be used and by whom? That’s the business set.

Then ask yourself how the information is going to be produced, who will be doing the actual report production, who will be using it to make presentations and how and when will they access it? What sorts of reports are they going to start off with? Where will they be in 18 months time and what will they be looking for then? That’s the user requirements.

This is a great opportunity to use prototyping in a creative way. Use your own domain knowledge to pick out a problem area and develop a report around the problem, highlighting how it’s impacting the business and why. Use a couple of these to show your stakeholders what can be done with your BI systems and get them excited.

Boiling the ocean and eating an elephant before breakfast

Be wary though of trying to solve all of the organisation’s problems in one shot. Plan your project so that it delivers capability and that it sets up a platform for further enhancements. Deliver incrementally and make sure that each delivery is useable and adds value to the organisation. Stop when the effort begins to outweigh the rewards, and on the way give the business stakeholders the time to adjust to and adopt the new systems and tools you have delivered.

(If you want to read more on this topic I have just found an article by Steve Williams about problems with requirements on BI projects.)