22 December 2008

2008 retrospective


That was a busy year…

Reflections are something that is as fundamental to the Agile philosophy of software development as iterative development… And regardless of your agility are always good practice. It’s easy when you are busy to just bunker down and get on with the work, but for your professional development and for your future customer’s sake you need to keep an eye on personal continuous improvement.

So, looking back at this year, what did I learn?

I can probably list dozens of things that I discovered but I think I can round it off into three main areas. And being an analytical type I can then plug a couple of sub points into each heading.

1. Requirements are your first priority for software projects
This year I reinforced my already keen knowledge of how important requirements management is to a project’s success.

My view has been and remains that solid requirements are the number one thing to focus on if you want a good project outcome. I believe that issues like executive sponsorship, strategic alignment, poor scope and value management etc are all aspects of poor requirements management.

(Particular nod to that neat IAG report from early this year.)

2. All about Scrum and XP
Nice processes/methods which make a lot of sense. While they have their limitations they also have plenty going for them. In particular they help avoid some of the cost burden of a development team waiting for a business client who keeps changing their mind!

However – both of these frameworks (?) push the concept of requirements management pretty much out of the project team. They push responsibility squarely onto the client.

Given that many clients don’t have much capability in this space, what are they to do? It won’t matter in small system developments, but as you scale up in complexity and size, an integrated and thought through product roadmap, architecture and feature set become more and more important.

See lesson 1.1 above.

3. Strategy is not as hard as people think
Strategic decision making suffers from the same problem as project requirements management. There is something to be said for simple models and seeking information by practically exploring and experiencing scenarios.

Iterative approaches to software development are one way of trialling these ideas. Another can be revealed through clever mechanisms like Alex Osterwalder’s Business Model Canvas.

What’s more important is having clear pragmatic goals. If you can visualise it, and can see practically how you’ll get there - it will be fine. If you need to rely on months of consultants’ time to establish your goals – you will be just as lost at the end as you were to begin with.

1. Tyner Blain is a great website
I learned that Tyner Blain is a really good reference source for printing/emailing pages to get short succinct messages across to project team members and stakeholders. Go there. Subscribe to the RSS feed and use the search engine. The chances are the idea you want to present has already been worked into a well though through article by Scott.

2. It's easy to go from trusted advisor to just another grunt
I (re) learned that no matter how much you are regarded in one environment, when you make a substantial industry/geographical switch you are back to zero reputation and virtually zero trust.

3. The BABOK is an exciting endeavour
I reviewed sections of the draft of the IIBA’s BABOK 2.0 and found it falling short of where I wanted it to go. Of course the BABOK committee feels the same way, but version 2.0 is a milestone in a journey, not an end result. And its goals are to improve the quality of requirements work in the industry, which I am sure it will do.

It was rewarding to me to participate in this process as I felt I had something worthwhile to say. It also sparked my interest in the discussions at the IIBA leadership team’s blog.

1. Teaching project management
This year I taught project management in a subject for masters degree students at MIT/Ballarat university and learned a number of details about good practices and why things are the way they are in our industry.

Thanks on that front to both the university for the gig, and to the textbook authors; Kathy Schwalbe, (Information Technology Project Management) and Cliff Gray and Erik Larson (The Project Management Process.) Both these textbooks have a typical dated feel you get in a university textbook, but at the same time focus on the human aspects of project management and so have timeless lessons in them.

The slide presentations from the lectures are here. I hope you enjoyed them.

2. Team blogging
This year I invited readers to join me in blogging here at Better Projects. Chris, Raphael and Andrew all wrote a handful of great posts for me, but dropped off along the way. Janet, however, has stuck with it. And usually her posts have been very popular, sparking posts on other blogs about the topic.

Thank you guys and thank you Janet for contributing.

3. The day job
Well… mixed blessings really, but a lovely bunch of people despite all the heartache.

4. Modern Analyst
Although my contribution has waned, the Modern Analyst site continues to grow in popularity among BAs. Not only do the forums provide lively discussions on a variety of topics, but the article repository just gets deeper and deeper. It was a pleasure to help kick that site off and to see it grow and thrive.

Drop by and say Hi to Adrian and the gang. Tell them I sent you.

5. Henry

Lastly, my little boy learned to sit up, eat food, turned one, and can even walk. What an amazing year it’s been for him and me.

Have a good break and I'll see you next year.

(photo by me, hosted at Flickr)

The answer to project failures is YOU

In 2001 Peter Meyer of AST Group (South Africa) wrote a top ten list of reasons why projects fail.

Here is his list;

The top 10 factors that have driven failed projects are:

  1. Project sponsors are often not committed to the objective. 
  2. Some projects do not meet the strategic vision of the company.
  3. Projects are started for the wrong reasons. 
  4. Project team members lack experience and do not have the required qualifications.
  5. Incomplete project scope.
  6. A project plan that is insufficient.
  7. Project value management is not put into practice.
  8. Insufficient funding.
  9. No formal project management methodologies.
  10. Not all project are going through a formal process.

The full article and descriptions can be found here.

I have two questions for you.

1. How many of these issues did you face at your organisation in 2008?
2. How many of these issues are able to be addressed by selecting one project process over another?

My view: Skilled and experienced people both in the project team and at the sponsor/steering committee are the essential ingredients for project success.  Process is secondary.  Tertiary even.

If you personally have a good track record you are amazing and the exception to the rule. Your customers may not tell you but they value the work you do highly (very highly) and you should seriously consider raising your rates.

You are worth it.

(Photo by B Tal, CC at Flickr)

16 December 2008

Reference Models

This week Rally's weekly newsletter had a short article in it about reference models for project mnagers.  Co-incidentally this week I attended a workshop where we were looking some something in that vein for a largish programme that's in it's early days.

The discussion was about rating the seriousnes of a problem so that it can be business-cased into scope.  In particular we were looking at non-financial drivers such as reputaion, regulatory compliance and customer satisfaction.  Most of what we discussed came out of some fairly standard risk management models.

Then we got to discussing the idea of developing organisational capability.  How do you quickly put a value to the quality of a solution?

With time and effot you can model out a whole of life cost - and see the comparison between a large up front investment vesus a small up-front - and the relative payoff over following years.

But at that initial stage - where you only want to spend 30-60 minutes on te topic, what do you do?

(photo care of kevindooley, CC at Flickr.)

8 December 2008


Just readiong some stuff... and was reminded that PRINCE2 stands for "Projects in Controlled Environments."

Aha! A disclaimer!

So, if your environment is not controlled, does this mean Prince2 is not for you?

5 December 2008

Missing Org Charts

It's been bugging me for a while how hard it is when you get to a new client organiation to find out who does what.

Organisational charts seem to be getting more and more abstract and high level.  Maybe it is one of those business assets where it isn't that easy to show the payoff.  For me, as a wandering project person, there is a real and tangible problem I face:
  • Who do I need to consult with?  
  • Who are the stakeholders to this project?
It's not always easy to discover them, and some of them won't come out and let you know who they are until the 11th hour.

As always there are techniques.

One method is to create your personal organisational chart and start with your immediate surroundings.  Grab one of the full timers/old hands on your team or in your physical vacinity and get them to put up a draft model on the white board.

Then get a copy of it into your notebook and walk around and visit the people on it at their desks.  While you are discussing their expectations of the project team, ask each one of them if there is anyone else to put on your org chart.

It's an okay process - meaning that is is not fool proof.  It still may not generate a complete picture very easily and you can't be sure whether some arm of the organsiation is missing (and everyone has forgotten about them.)

The next step is to investigate the lessons learned log from previous projects. (If you have one.)

Then - run the model by your sponsor and discuss the areas that are likely to present trouble or particular challenges.  One thing to keep an eye out for is business units with conflicting goals or radically different priorities.  An active discussion like this will elicit better results than a simple presentation of what you have discoverred so far.

I hope this helps you discover all your stakeholders easier next time you start up a project.  Maybe it's something to attack this week?

Or maybe you should just turn the office Christmas party into a networking opportuunity and use the event to walk the floor in once concentrated effort.

Disney Org Chart by shadowstorm, CC on Flickr

3 December 2008

C.R.A.C.K. Requirements managers

Call in the S.W.O.T. team, we have a C.R.A.C.K. addict in the blogging community...

Dear B.A. readers

As our 'user representatives' you need to be a CRACK Business analyst.

Researchers (Barry Boehm no less) have looked at what makes the difference between effective projects and failed projects across many dimensions. One particularly relevant one is the personal attributes of the requirements manager.

What is most important and how do they break down into tangible things?

Collaborative -You work as a team member with both user groups and the development team. You are a boundary spanner and work across organisational boundaries.
Representative - You are genuinely representation the best interests of your (real) customers, and they know it. They have given you authority to represent them, not just at a formal level but at a personal level.
Accountable - You are willing to stand by your decisions, but you are also willing to wear the consequences of your mistakes.
Committed - You want the project to succeed to the degree you are willing to work beyond the requirements of the job description.
Knowledgeable - you have sufficient knowledge of the development process, of the customer domain and of good business practice generally, and this is sufficient to help you make on the spot decisions without having to refer all questions upline to frontline users or customers. This usually takes some sort of ongoing market research to establish and maintain.
Sure we can joke about the acronym, but take a look at what is needed to be effective as a customer representative these days.

It is likely you have strengths and weaknesses in different areas. It's worth collaborating with your friends in the IT team and in business units to help augment or develop any weak spots.

Further reading @ Tyner Blain under the ever so droll heading of "Crack users are addictive!"

Photo by eqqman CC @ Flickr