19 December 2007


Thanks readers for keeping on coming here and reading what I have to say.

It’s the end of the year and time to take a break for a few weeks.

If you want to be alerted when I start up again, I recommend you subscribe via feedblitz (see the box on the top right corner?) or via the RSS feed. That way you’ll get an email or notification when I kick off posting again in the new-year.

In the meantime if anyone has any suggestions on topics to explore for 2008 let me know. I’ll be happy to take advice.

16 December 2007

9 Boxes

While we are on the topic of requirements analysis here is an intersting model designed to help people understand how to effectively develop business requirements.

The Nine boxes is a neat model that helps new analysts, or people who don't do this sort of work very often break down the process of understanding the business issues and what needs to be done. The diagram is below. Read more about how to use it at agile software development.

I discoverred this via the Herding Cats blog.

Carnival of Business Analysts #5; Requirements Analysis

Welcome to the December 10, 2007 edition of the Carnival of Business Analysts.
Hello everyone and welcome to edition 5 of the Carnival of Business Analysts. Regular readers will know that since edition #3 each new edition of the Carnival of Business Analysts has been following the knowledge areas described in the BABOK. I hope you find some useful info in here, and if you know of any other good articles plug them into the comments below for others to check out.

Firstly we have Chris Baker who provides a very on-topic article called Requirements Analysis at his blog Usability Notes. In it he describes the challenge of communicating requirements across the business technical divide, offers up an acronym for checking off your requirements and the challenge of dealing with competing requirements. A good opener for this topic.

Secondly, Jeramie Mercker delivers A Requirements Analysis Primer at Tech Links. In particular read his rules of thumb for some very practical guidelines on how to tackle requirements analysis. Lalit also offers a list of Types of requirements at Rapidshare Ebooks

Next up is Gareth Thomas Hill’s blog with his post on Quality Software Requirements with a checklist of what goes into good requirements and what identifies bad requirements. You can also read about an ISO9001:2000 approach to requirements assessment at (ISO) Quality Manual Chat.

Ahamad complements the QA perspective with a testing one in Requirements testing at his Software Testing blog. Remember the V-model and Test driven development? The same principles apply to requirements; they should all be testable and you should basically have your test cases written before you get your requirements signed off.

Zuzar provides a list of four major problems with software requirements inMost common errors in requirements analysis at the Blue Mango Blogs. Don’t make these mistakes when putting yours together.

This discussion on Requirements Analysis has to include the topic of business rules and business process management. Theresa whole big discussion just on how these two topics interact with requirements. Have a read of Requirements vs Process and Rules at Roeland Loggen’s Process transformation blog.

The Role of Architecture in Business Analysis is discussed at Ashok’s blog space by Michael Rosen. Architecture – both business and technical is an increasingly important part of business design and management. How does it fit in with project requirements analysis? Go take a look.

The Art of Commerce blog has a couple of good posts on requirements. The one most pertinent to this months theme is Should you trust your analyst? This post sets up your stakeholders to challenge what you give them.

On the topic of specific Analysis Techniques Dale Wolf posted an article on Conjoint analysis at his Perfect Customer Experience blog. Also Jim presents Common Cause Variation at The Kaizen Business blog. This topic is one of the six sigma tools and is a process analysis tool.

Warren Wong presents some financial perspective in What Is The P/E Ratio And What The Price Earnings Ratio Means at Personal Development for INTJs, with "A description of what the P/E ratio is and what the price earnings ratio actually means."

Interestingly we also have an article from a lawyers blog; Noric Dilanchian presents How to make contracts more certain and less costly posted at Lightbulb, saying, "It's time to stop believing the myth that lawyers can provide legal protection with words alone. In addition to words, protection in contacts requires knowledge and know-how regarding business process, policies, training, standards, and codes of conduct. This article discusses why this is so in Australia, the United States and other countries with contract law derived from the law of England." My view on this article is that it provides an interesting alternative view to many issues BAs face with projects.

Off topic, but close enough Sagar gives us The eCommerce Customer Service Checklist: 50 Things Every Business Should Be Doing posted at Virtual Hosting and James D. Brausch presents Business Systems Also Improve Sales And Customer Experience posted at jamesbrausch.com.

There you have it; the 5th edition of the Carnival of Business Analysts. This particular Carnival series is a special way of highlighting the excellent contribution blogs can make to the body of knowledge for 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.

Next month’s topic; Requirements Communication, and submit your posts by January 27th!

Read other Carnivals of Business Analysts here
(And past posts and future hosts can be found on our blog carnival index page.)

13 December 2007

Learning about Requirements from Star Wars

Here is a fresh view on managing projects.

In particular on managing the user experience through the lens of lessons learned from George Lucas' Star Wars experience.

Good design and user experience are always important features (although sometimes more important than others.)

I hope you find a lesson in here for your project life.

(If you get a 'not available' message above click through to Slideshare and watch it there.)

11 December 2007

Thanks for the kudos

This blog has started to accumulate links and acknowledgement from other websites. Thanks people for reading and for talking about this blog!

Most recently Troy Worman at Orbit Now! includes us in his (very long) list of Outstanding Blogs for 2007. Thanks Troy!

If you are looking for something new to read, go have a look at his list.

3 Great Knowledge Management tools for Project Managers

A couple of Project Management academics, Besner and Hobbes (2006) ran a survey on processes and tools that project management practitioners use with a view to identifying ways of improving project performance. Among other things they identified 3 great tools for lifting your organisation's project management performance.

The investigation focused mainly on project managers and identified that knowledge management tools – usually databases - such as lesson learned, risks and cost estimates versus actuals were excellent tools that were under-utilised.

The thing about these systems is that you can’t effectively take full advantage of them by yourself. These information repositories need to draw on the organisation’s or the professional community’s historical data. It's about sharing knowledge and learning from those who have gone before.

Does your organisation keep this information somewhere? Is it hidden away in a project file or is it readily available through an intranet or project office reports? Depending on the answers to these questions there are two action items for you today.

If you do have these assets in your organisation - Be smart: Go and find the repository, read it and share the information with your team. Be Altruistic: Make sure your all projects’ information goes into the repository before your close out and move on.

If you don’t have these assets in your organisation - Consider how much time and money could be saved by better knowledge management and speak to who-ever in running your project office about what needs to be done and why.

Tip: If you use, or are putting together a balanced scorecard for your project office, the quality of these repositories can become a measure of effectiveness in the innovation and learning quadrant.

Source: Claude Besner and Brian Hobbs (2006) “The PerceivedValue and Potential Contribution of Project Management Practices to Success" Journal of Project Management, August 2006

10 December 2007

Importance/Urgency for Meetings

Let’s face it, we love our meetings. We love the opportunity to interact with stakeholders, to grab the whiteboard marker and to draw all sorts of diagrams demonstrating our ability to think creatively and in a structured way at the same time.

Meetings are a critical part of us getting our job done and without them we would be spending our time fretting over Gantt charts and spreadsheets wondering whether everything was really going to plan.

Not everyone shares your enthusiasm. The more time people spend in meetings the less time they feel they have to do their ‘real” work. And the less effective meetings are the more frustrated participants can get.

As a regular reader of Better Projects you already know a few important things about meeting management. You always have an agenda, and clear objectives. You always try to give people plenty of notice about meetings, and you always follow up with minutes, or emails confirming key points and actions.

Today I wanted to cover off a technique to help you keep meeting content on track and focused where it should be. It’s best applied in workshops rather than smaller meetings, but can be scaled to the situation. It's another application of the urgency/important matrix.

Efficiency is often considered important, right? When you are a project professional one of the main ways this impacts you is in the number, duration and quality of meetings. This framework can help you speed up your meetings and keep them foused on the highest impact issues.

Take in a printed matrix and some sticky notes, or draw up this diagram onto a whiteboard and as things come up that are off agenda, or agenda items drag on for longer that appropriate, stop and spend a minute assessing where on this grid the issue belongs. Get consensus from the room on its appropriate place and move on.

Important issues can be addressed later in the meeting, and other items can be dealt with as appropriate afterwards.

Try it out and let me know what you think.

3 December 2007

Requirements Engineer ≠ Business Analysts

For a while I have been reading the Requirements Engineering Yahoo group, and from time to time I scan the RE Journal. When I do I always put down my reading with a hunch that Requirements Engineers and Business Analysts are not the same people.

A quick example to illustrate my point; when RE’s talk about quality the phrase “complete and accurate” comes up very quickly. In BA discussions the emphasis is on “understanding and effective communication.”

Both groups are talking to the same point, but one is focusing on the artefacts while the other is focusing on the people. The ‘quality artefact’ approach will be more important in highly formal and contractual environments, while the people (outcomes) based approach will be more effective when the team is working in a more informal or united way (e.g. less likely to be a cross-functional or client-vendor team.)

Another point to note is that the business analyst is not just a requirements manager. Requirements management is a critically important job and a key part of the business analyst’s role, but the BA looks beyond the requirements to a wider range of issues that orbit the business problem the project is there to address.

Business analysts are looking deeply at the business problem, and the requirements are just part of the solution. In particular there is the constraints of the environment, the change management-effort required and benefits realisation, not to mention things like enterprise analysis, developing project business cases, project portfolio management, stakeholder management and the many other things BAs do in the course of delivering the project.

The IIBA’s BABOK spends much of its content going through the requirements management process and rightly so because requirements management is a large part of a project BA’s life, but just like the contents of the BABOK it’s not the exclusive content.

The bottom line of all this is that Requirements engineering is just one of the many things a business analyst gets involved in. Requirements management is a key part of a business analyst’s role, but not all BAs are managing requirements and not all requirements managers are BAs.