24 December 2009

Harsh Jegadeesan on Use Cases

Here is another installment of my Use Case series, faciliated by the wonderful people who contribute to Slideshare.

(I am currently on the beach in Thailand. Back next week.)

23 December 2009

On Holiday

Thanks for reading in 2009.  See you in the new year!

19 December 2009

Papercut/

There is a great new project management blog from an experienced PM called Papercut/.  One of my favorite things about this blog (and probably yours also) is the great graphics that show up there.



You might also like the neat tools he shares.

Check it out now.

You can thank me later.

Bloggers update

A status update on the group blogging thing; I have invited the people who have volunteered to contribute to a Better Projects discussion group.  Next step is to generate some ideas and content and then we'll see some new perspectives flow through.

18 December 2009

Requirements capture and Use Cases

Here is the second in several slide decks I intend to present on Use Cases. If your job involves analysing business operations and developing requirements for projects you should know this tool.

17 December 2009

Breaking down the WBS - redux


This is a quote I used in my 7th-ever-blog-post.  It's from Max Wideman, who is never wrong.

"...The most useful first step in managing a project of any size is to start by breaking down its scope, as defined above, according to a well-established and logical sequence. This sequence looks something like this: First according to geographically discrete components, if this is applicable; Second according to time based phases and stages, where each has a clear deliverable; Third according to intermediate or final major deliverables; Fourth according to discrete structural, process, system or device components. Finally, into deliverable elements that can be associated with distinctive types of people-skills or resources."

I can look at this years late and say; Yes, this makes sense to me.

What was your favourite Projects blog for 2009?


Andrew Filev's PM2.0 blog has asked what's your favourite PM Blog.

Now, this blog is on the nomination list but isn't pulling many votes. Come on people, click through and put in a good word for yours truly!

Cigars and whiskey all round if I win!

ITIL's 7 Rs of change management

I am butting up against the ITIL CAB process on a regular basis.

It's not the process itself, it's a combination of the tool/process implementation that has come with it and some documentation naivety or slackness on the team, which has forced what feels like a particular bureacracy anti-pattern.

So tonight I research the CAB process in more detail.

The first thing that catches my attention is the "7 Rs of Change Management." In ITIL's context this has nothing to do with managing people through change - it's about managing complex IT environments, and trying not to break old things when you introduce something new.

The 7 R principles are worth sharing even if you don't have ITIL in your house. You could apply them to project change requests as well. You could even apply it to requirements and work packages.
  • Who RAISED the Change?
  • What is the REASON for the change?
  • What RETURN will the change deliver?
  • What RISKS are there is we do or do not carry out the change?
  • What RESOURCES will be required to perform this change?
  • Who is RESPONSIBLE for this change being performed?
  • What RELATIONSHIPS are there between this and other changes?

16 December 2009

Project Management 3.0, coming your way

Project management 1.0 is all about good technical processes around planning, managing, tracking and delivering. Where people say it falls short is in dealing with complexity and people. Managers are too busy focusing on 'scientific' metrics and historical results to be able to help with problems and issues.

So project management 2.0 helps people talk to each other by handing them communciation and collabroation tools and giving them processes that enable them to self-direct. Self Direct towards what end?

That's where leaders and product owners come in. They give vision and focus to teams. They point the way, and rally the team towards a common goal: a great product, a happy customer or a shareholder dividend.

So, that sounds good, but what if you are short on good leaders? Or what if your leaders are busy out there seting visions and are too busy to come back to the workshop?  Or what if your leaders are just plain-old-wrong about their product or project vision?

And just how do you transform vision into action?

Enter Project Management 3.0; where the valuable art of management is applied and balanced with talented leadership.

(Did I coin the phrase first? Alas, no, I am at least a year too late.)


Photo = promo shot of Ed Lawler, the management 3.0 guy.

Volunteer bloggers

Thanks to those of you who have responded to my call for help in the coming year.  I'll follow up on the weekend.  In the meantime; if you want to do some regular or once in a while postig here get in touch.

14 December 2009

Complexity or Capcacity; what type of problem do you have?

Ron Ashkenas blogged an opinion piece on the US participation in Afghanistan.In it he called out problems as one of two types; problems of capcaciy or complexity.

Capcacity problems are ones that are fixed by adjusting the allocated resoruces.  Complex problems require a creative approach to solving them.  It's a nice idea and one that can help in your problem solving techniques.

Unfortunately most apparent problems we face are made up of many problems of both types bundled together.

For example; the problem of estimating a project presents us with the challenge of getting things done faster (apply more people) and keeping the whole thing integrated and aligned (develop systems, methods and controls.)

The purpose of this post is simply to call out that problems are not EITHER about complexity or capacity, and in reality the problems we have are made up of elements from both dimensions.  We can still use the indicators to help us in our problem solving appraoches, but can't afford to be simplistic in our thinking.

With both complexity and capacity placed into a 5x5 grid you get something that looks, appropriately, like a risk matrix.


Things at the right require a creative approach.  Things up high require interventon on the resourceing (and budget) front.  This can help you decide who to assign to the problem solving and what techniques you need to apply.

Not enough resources?  It's a sponsor issue; as you'll need to adjust scope, schedule or budget.  Stcuk on a complexity problem?  That's probably one for the team.

I wonder whether an assessment on this matrix would align to risk assessments?  There would probably be some correlation, but it may not be a cause and effect relationship.

11 December 2009

Eran Toch on Use Cases

For the next few weeks I am going to grab a handful of slide decks about Use Cases and post them here.

For those of you new to the work of the BA they are possibly the most popular way to define functional requirements in the industry today.

(They are not the only way, nor even the best way.)

10 December 2009

Volunteer bloggers wanted

Hi everyone

In 2008 I asked for help on this site, and as a result 4 people volunteered to post here. Their contributions were some of the best and most popular content on this site.

I'd like to repeat the offer for 2010.

If you would like to occaisionally or regularly blog on projects, management, requirements, or IT here is your chance to step right into an existing readership.

Email me if you are interested.

9 December 2009

A comment on "PMOs and Sysiphus" by Randy Englund


Bureaucracy is a tool used to control.

It controls change and controls compliance with defined standards and it tries to control how people do thier jobs.  Bureacracy is by it's nature fairly change resistant.

When Randy Englund uses Lewin's rubber band metaphor to describe how change only lasts as long as the tension is maintained, I found myself agreeing with reservations.

The rubber band story in the blog post is about maintaining the tension, from an organised state holding back from a snap return to dissolute.  In particular Randy has a call to action to project professionals; that our projects goals are secondary to something larger - the organisation's ever growing maturity and capability.

What are my reservations? I think that thee are plenty of techniques and tools to help us guide people through change, and that things, when managed well, will not snap back like a stretched rubber band.  But that last sentence is loaded, so it doesn't apply to every scenario.

Planning and executing change are important.  But equally important is nurturing it.

6 December 2009

What is a specification?

"It's a fairly well developped science..."

Part 5 of a Lecture Series on Software Engineering by Prof.N.L. Sarda, Prof. Umesh Bellur,Prof.R.K.Joshi and Prof.Shashi Kelkar, Department of Computer Science & Engineering ,IIT Bombay.

This is for beginners to the SW engineering and requirements management world, but is worth revisiting form the more experienced (with an hour on their hands.)

It starts with the basic question: What is a specification?

It is full of pertinent tips including;
  • Don't specify too tightly
  • What will eventually be deliverred?
  • How will costs be managed?


1 December 2009

Where is your focus?

As a project manager you have different stakeholders and orientations you need to focus on.  It's tough to cover all directions at once and you probably have a preferred approach.


Gill Corkindale at HBR writes about the inward and outwad facing dimensions of leadership.  Inward facing (ie team facing) leaders get things done via their teams, outward facing leaders are managing their careers and potentially operating at a macro level beyond their immeditae scope of work.

Her post is interesting, as are the comments. The bottom line advice is to know yourself and cultivate capability in both styles.

I'll take a different tack and say be aware of your personal strengths and weaknesses and balance it out with your team.  This can mean a PM/BA combo, or a pairing per the consulting mode.  You aren't in this alone.