Search This Blog

31 October 2007

make it blue (2)

Another little Requirements Management cartoon, care of Powerpoint.

30 October 2007

Dimensions of Quality

Projects have certain quality standards they have to meet. Some are easy to measure - system avaiability for example. Others are a bit hazy - like useability.

In the past I have written about how there are different ways of defining success for projects. There is compliance with the plan, there is meeting the right ROI threshold, and so on.

Quality still seems like an intagible and ephemeral thing to me. I can't lock it down and I want help.

Do any readers out there want to point me at articles, books or blogs that nail the concept of project quality.

29 October 2007

3 tips to improve requirements management

Darren tells us that user requirements are at the top of the list of reasons why project fail. No surprises there.

But he elaborates; it's not the elicitation of the requirements, it's the communication of them to the developers, and the dev team's understanding of them that is where the problem is occurring.

It's no surprise when you consider the long liked communications process that often occurs, especially in large organisations. It's even more obvious when you consider outsourced development houses that don't have much business or even industry domain knowledge. How does a fresh develop with no history with the client organisation fill in the gaps in the communicated requirements?

Avoid requirements failure by doing these things;

  1. Have developers feed back their interpretation of requirements to the stakeholders and clients. Do it early and often. Use workshops, wireframes, prototypes, or documents, but do it.
  2. Bring the subject matter experts and requirements owners into the same room as the developers. Get them talking to each other. If you can't be in the same room, arrange regular meetings. Don't rely on written communication.
  3. Make sure your BAs are trained and highly skilled at requirements management (ie not just elicitation, but the whole shebang.)

Business Analysts are the main key to successful projects. Pay them more and pat them on the back when they do a good job.

27 October 2007

A short explanation of the SLDC

Sure it's an advertisement, but it's well done.

This animation does a good job of describing the software development lifecycle. Useful for people new to the process, and for people who want a refesher on the whole end to end cycle.


25 October 2007

Reminder; the Carnival of Business Analysts

Hi readers

Time for you to contribute. Each month I publish a carnival of business analysts which highlights a number of blog posts and articles on... you guessed it; business analysts.

I am also providing a theme to help you pick and choose your posts.

This month's theme is Requirements Elicitation.

And time is running out! Send me a blog post you have read, a white paper you wrote or an article you have downloaded and not got around to yet. I'll publish the carnival next week.

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.

23 October 2007

Cumulative Advantage and Managing Change

When you are managing projects (or requirements) in a large complex stakeholder environment you just know that dealing with people is going to be the hardest part of the job.

Ever wondered about why people work well or not so well with your project (or it's requirements)? Why they put up objections or get on board? Or what oils the wheels of organisational politics?

Here is an article by Duncan J Watts on the topic of Cumulative Advantage – it investigates the influence of markets (and communities) on decision making.

What do people want? It’s largely affected by what they think other people want. You can use this when managing change, or working to get stakeholders on board with your project’s requirements/scope/objectives.

Read the article, come back here and tell me if you think it’s a useful piece of information.

I picked up on this article care of Seth Godin’s blog. Duncan J. Watts is a professor of sociology at Columbia University and the author of “Six Degrees: The Science of a Connected Age.”

20 October 2007

Just Enough Structured Analysis by Ed Yourdon

Ed Yourdon is one of the biggest influences in modern software methods. He wrote several books and over time has migrated from a view that highly structured processes will improve project results to one where he believes the success factors are quality people and in keeping bureaucracy out of the way.

You might have heard of such titles as Death March and Managing High Intensity Projects.

Adrian Marchis of Modern Analyst recently pointed me at a free e-book by Yourdon called Just Enough Structured Analysis. (You can download it here.)

With over 600 pages from a world class expert on software development there is bound to be some great insights in here. I'll be reading it over the next few weeks. If you have read it and can offer comments please tell me what you think.


There is a wiki version of the book that you can use to keep track of the content over time.

You can access it here.

18 October 2007

A List Apart's Web Industry Career Survey

A List Apart is a website for people in the website business. They have recently surveyed over 30,000 web professionals (including analysts and project managers) and asked a wide range of questions about what they do, how long the have done it, how they are rewarded and whether they like doing their web thing. You can read the report here.

One of the things that I picked up as I read through it was the question on "How do you stay current?"

By far the most popular answer was by reading websites, blogs and zines. (Trial and error was the second most popular way of learning, which reflects the developer centric nature of the responses.)


I am hoping that this blog is one of the useful resources of the many project workers out there. Recently I have received several messages telling me that this is a good blog and a useful resources for both junior and experienced project workers; mainly analysts, but also a few project managers. Thank you for the feedback. It helps motivate me to keep doing it.

17 October 2007

BA Skills And Knowledge Audit

This is a tool to help business analysts assess their skills and comptencies against the contents of IIBA's BABOK.

Bear with me - it was my first attempt at using Slideshare. You will probably get a better effect if you view in full screen mode, and if you want to use it as a workbook you can download it.

16 October 2007

make it blue

A comment on Requirements Management care of my friend Powerpoint.


Glenn Alleman has a great blog - Herding Cats, and its a beauty of a project management site. He works in the aerospace industry so you get some good perspectives from the heavy end of the project management spectrum.

I mention him here because he points us to an excellent resource; The US DoD version of a PMBOK. You can download it here.

14 October 2007

Projects and Personalities

Which personality type are you?

Project teams are groups of people, and it’s good people that make projects succeed.

Sometimes you get to put the team together yourself, but usually at least some part of the team is handed to you. How do you make sure the team is optimised for best effectiveness when you can’t control who is in the team?

The answer is in understanding what you do have and adjusting your style for the individuals on board. Once you understand the people you can then manage them appropriately; according to their needs, not your preferred style.

Understanding the profile of your team members will also give you an indication of whether you have any skills deficits which need to be addressed.

The quickest way to this understanding is a short and honest conversation with each of your team members. The best way is by developing an ongoing relationship with each one of them where there is an open and trusted conversation happening.

Beyond that there are tools and frameworks that you can learn about that will help you analyse and address the needs of your team.

Max Wideman has an article on his website discussing how project teams need a variety of personality types on board to be fully effective. Wideman’s article considers both the competing values model and the Myers-Briggs personality models as ways of dividing up people into the ways they are best suited to contribute to projects. (His theory indicates that effective projects manager personalities are in short supply.)

Co-incidentally there is a discussion thread at Modern Analyst on personality types and a question about whether there is likely to be a consistency in business analysis. For example the role requires certain traits like attention to detail and good communications skills.

I encourage you to take a quick Myers-Briggs test and report your results to the Modern Analyst discussion board.

12 October 2007

How much Modelling Detail is too much?

This is the second post contributed to Better Projects by Nathan Johnson of SNJ Consulting. (The first is here.)

How much Modelling Detail is too much?
One of the biggest dilemma's BA's face is how much detail to include and to satisfy the users representatives, the business and the development team. It is best to avoid detailed design like the right hand side of the diagram below; use cases should never be 'fully loaded'.

Most of the time you will find that the essential software requirements are often stable enough, however the design associated with the requirements is often very volatile and shouldn't be described too much early on.

Business analysts must keep their thoughts in the problem domain for as long as possible and resist becoming fixed on designs, screens or layouts until they have understood and conveyed the business domain comprehensively. There is nothing worse than spending days and even weeks on design for a functional requirement and then be told that 'piece' of functionality isn't required anymore.

What level of detail must a business analyst describe? And how much is too much?The more you document, the more you will have to change. Scott Ambler says that “barely enough is good enough”.

Business analysts and application development departments can unintentionally abuse use cases much more than they need to be.

Most would agree that you do not want to build the system on paper first and try to think and incorporate every single viewpoint and must have design requirement (buttons, backgrounds, URL’s etc) Most of the time, as history has proved, too much documentation is simply a waste of time and money.

Why? Well because during this ‘discovery phase’ it is human nature to think, discuss, validate and reject many ideas, but by documenting most of these even in a simple format

I have seen some BA’s basically document the requirements specification at the command of the programmer, detailing every single error message, the exceptions and technical components called.

At this point it is obvious the BA has lost his/her role in the project and has become a “gofer”.

The requirements specification normally describes the business and user functional requirements. Real software design doesn’t usually start at this stage of the project and maybe the BA has been roped into design considerations from a simple harmless discussion.

Providing business analyst services for clients worldwide, we will identify your business problems and offer clear, concise and straight forward requirements solutions that meet the needs of your users and satisfy your business objectives.

Nathan’s consultancy is SNJ Consulting.
They have been providing business analyst services for clients worldwide. They will identify your business problems and offer clear, concise and straight forward requirements solutions that meet the needs of your users and satisfy your business objectives.

SNJ’s areas of expertise are; Business Problem Solving, Feasibility Studies, Business Cases, Business Analysis and Requirements Gathering, Process Re-engineering, Workshop Facilitation, Client Management, Requirements Mentoring and Coaching, and Requirements Quality Assessments.

10 October 2007

Use UML models at the first opportunity

Nathan Johnson is a Senior Business Analyst working around Melbourne. We met recently and discussed the role of the BA, the current explosion in demand for Analysts and the importance of building a community of practitioners in the city.

He also agreed to make a guest contribution to Better Projects about UML modeling. Thanks Nathan for the contributions.
Here is part 1 of 2 articles on modelling.

Use UML models at the first opportunity

Business analysts should model scenarios, functions and discussion points from day one of the project.

Modeling helps break down communication barriers and encourages team members to discuss options and solve problems

Use UML models at the first opportunity, even if your department doesn’t practice them officially. They will be enlightened to see simple, clear descriptions of your requirements, compared to the structured techniques from the past. Concentrate on the use case diagram and a conceptual class diagram at first.

If you have a Business Analyst who does this exceptionally well in your organisation, pay them really well and try to retain them. They are very hard to find.

Many business representatives instantly warm to the use case diagram, because they can see themselves within the diagram, playing out a role or using the new system. The use case diagram is a great way of building rapport with your business representatives. Encourage them to help you model this diagram, include their business vocabulary in the use case names wherever possible.

Try to avoid users corporate job titles as the names of your actors in the use case model. Use actor hierarchies to show them where they may fit in exactly.

Nathan’s consultancy is SNJ Consulting.
They have been providing business analyst services for clients worldwide. They will identify your business problems and offer clear, concise and straight forward requirements solutions that meet the needs of your users and satisfy your business objectives.

SNJ’s areas of expertise are; Business Problem Solving, Feasibility Studies, Business Cases, Business Analysis and Requirements Gathering, Process Re-engineering, Workshop Facilitation, Client Management, Requirements Mentoring and Coaching, and Requirements Quality Assessments.

IIBA Australia - October 2007 events

Keynote: Dr Kelvin Ross - "Quality Starts at Requirments”

Sponsored by KJ Ross & Associates and M&T Resources

Brisbane: Thursday October 18th
Venue (Sponsored by Wedgetail Finance & Investments): Francis Rush Centre, St Stephen's Cathedral Food and Drinks from 5:30pm Sponsored by Borland
Click HERE to register

Sydney: Tuesday October 23rd
Venue (Sponsored by Cliftons): Cliftons, 200 George St. Sydney 2000 Food and Drinks from 5:30pm Sponsored by Borland
Click HERE to register

Melbourne: Thursday October 25th
Venue (Sponsored by OptimiseIT): Telstra Level 1, 242 Exhibition St, Melbourne, Food and Drinks from 5:30pm Sponsored by Borland
Click HERE to register

5 October 2007

The time has come for a distinctly off-topic post. My personal project; Evaluator has finally gone live.

Months of working after hours, working with an excellent web design firm, Get Started and help from several great people along the way including Justin Findlay, Mareika Jacobs, Toby Dargaville and Callan Robinson have finally gotten us to launch. Thanks to you all for your various contributions.

Evaluator is a simple concept. It's a single web location where you can go to get property reports for any home in Australia. The reports we can provide are valuations, building inspections and pest inspections.

These are the typical reports you would get when buying a new property - and if you are in the market for a new property you are potentially one of my customers.

The website is not perfect, but with the gaps being filled by myself and the lovely Charlotte (mother of Henry) we are sure we will be able to provide a quality service. And we will make further improvements as the business matures.

Its an exciting time for us; new baby, and now a new business. All I have to do now is finish the PM4Law Thesis.

In the meantime can you do me a favour; spread the word to people that are in the property market.

Visit the site here:


Salary Survey for Project Workers 07-08

Michael Page has published its 2007-08 salary survey for the Australian technology labour market. You can get it here.

Senior BAs can earn up to $130k, while project managers can earn up to $150kpa. Programme managers can pull down up to $200k.

Project managers top salaries have not increased, but both BAs and Programme managers have increased by $15k and 20K respectively from last year. Expect further rises as demand for skilled people outstrips supply.

If you are looking for trends you can access the previous years report here.

3 October 2007

Software Product Success Stories - a meme

In what has the potential to be a very inspiring post, Scott Sehlhorst at Tyner Blain has challenged us to tell a story about when we helped make a product successful. It will be a nice counterpoint to all the stories of project failures and disappointments.

The rules of this meme are simple; tell a true story of something you did that made a product successful or more successful than it was otherwise going to be. Be specific. Be anonymous if you want to. Read the details here.

As you'd expect my example of something I have done that has made a product more successful is comes via a project…

Focusing on outcomes rather than processes
When you work in a large bureaucratic organisation process often becomes the way you think, let alone the way you work. Here (and at Tyner Blain) we believe that following the processes reduces risk but often doesn’t get you to the end game.

In this story, before I turned up the team had followed a usual corporate waterfall approach of getting high level requirements, and chasing down estimates from developers and infrastructure people. The tool was going to be a simple web interface to back end systems with existing interfaces all built and ready - that a small business could put together in a week. It was quoted in the millions.

The team had followed the business process and come up with an outcome that wasn’t going to fly.

I was invited to participate. My job was to look at the requirements, which I was already reasonably familiar with, and find a cheaper solution. I worked with the lead business analyst on the team, who was smart and capable, but having been on the job for a while, and led by a PM who had a strong “follow the business process” orientation he hadn’t been able to get to the right solution.

We worked together and started with removing the constraints of the local business processes. Then we looked at the end outcome; which was the main functions and the constraints of time and costs. I drove the agenda that the solution should be cheap and quick, because we knew it should be.

A bit more work with an external solution provider; getting a prototype up and showing the key stakeholders what we were intent on building, and we had endorsement to go ahead.

We had gone outside the usual processes – going to an external vendor without documented scope and business requirements, building a prototype off verbal requirements and come up with a solution less than 20% of the initial estimates. And our lead BA was now re-invigorated and led the team (under a new PM) on to an on-time, on-budget on-scope (
OTOBOS) delivery that met all the business needs.

My time on this project was brief – about two months but it brought me satisfaction in that it set a new precedent for getting things done properly, shifting the view from the mandated processes to targeting business value, and it enabled an excellent BA to move outside the constraints that he had found himself in, and to again become motivated about the work.

Tag you’re it; Mike Ramm, Elizabeth Harrin, Bas de Bar, Pawell Brodzinski, Rajeev Sing and Adrian Marchis. (Don't forget to link back here and to Tyner Blain. )