31 May 2009


Alan Tsuda writes a blog post observing team behaviors. Are all groups of people teams? Not unless they have a common goal, and even then, not always.

Somewhere else (It was at JB's practical analyst) recently I read about how project teams are often not really teams as they don't get the chance to establish common values and learn to work together.  Instead each individual contributes in his or her own technical area and hopes the project manager has developed a coherent integrated plan.

Maybe.  Maybe longer projects do form as team.  This has been my experience in most cases.

But Alan's comments are about teams acting as a group to overcome common problems, and I do see groups who are nominaly teams, but where individuals will sit back and watch their
'team mates' struggle and potentially fail at their task.

(In my team we are constantly trying to kill this behaviour, but it's hard.  Those individuls have to want to change.)

Alan's post got me thinking about how to plan for change.  He led me to trust and competency as two key issues.  I put up some ideas below.

In this model you see two dimensions of technical capability and trust as drivers for teamwork.  If you have both, then your job will be to help the team optimsie it's performance.  If the team is lacking on one dimension but has the attributes of the other, you'll work with the team on enhancing those weaker attributes.

If your team has poor technical capability AND a low level of trust, congratualtions: you have problems.  How do you get out of this quadrant as quickly as possible?

If the secret of 'team success' lies in trust and competence then the fastest way out of the bottom left quadrant is to hire in leadership and talent.  Naturally your best hope is to hire leaders who have technical capability.  They don't always come together, and depending on your local labour market and your budget this may be a challenge.

(A funny thing about tough economic conditions is that finally there are penty of great staff avialble and affordable out there, but many organsiations have implemented a hiring freeze, so you still can't get them.)

So we my have to look for other solutions to hiring in help.  One  option put forwad by one of my team members was for everyone to go home one day and have a think about why they have signed on to this team. His question was "If you are not committed to our success, why are you here?" 
Another pathway to better teamwork may be a series of small steps.  You may strike a blow for trust by introducing some team events - pizza for lunch, co-location, drinks, whatever.  Compliment this with things like training or pairing team members on tasks.  Step by step they can build themseleves into a team rather than just a group.
Another pathway may be to build a strong team culture.  I emphasize this at the team level, rather than the organsiational level.  You want the team members to define themselves at work primarily as a member of your projet team.  Their sense of purpose and achievement should be tied to the project's outcomes.

These are just a few ideas thought up on a Sunday afternoon.  Maybe you should hit all these approaches at once. And there are others also.

If you have read this far then this topic probably interests you.  Maybe you have some experience in this area?  What are your thoughts?

28 May 2009

De Bono's 6 Thinkng Hats

I used to walk past the De Bono centre on Melbourne's Collins street every day.  During that time I also pulled out Dr De Bono's thinking hats model in several workshops.

How is it useful?

Once you have a team performing strongly as a group you tend to get a bit of groupthink.  The thinking hats apply a structured way to get people to think differently about a problem.  This helps break out of that groupthink so that you can get a bit more creative about identifying and solving problems.

Take a look at the below slide deck for more information.

27 May 2009

BA Competency model

The Australian Business Aanalyst Association (ABAA) provides a downloadable competency model for businss analysts.

If you are looking for a tool to help you (or the BAs working with you) then this model may help assess where you (they) are today.  Then, based upon the needs of your team, you can work out a development plan aimed at elevating competencies.

26 May 2009

Global Issues in Project Management

What's going on in the world of project management?

More collaborative contracts, more outsourcing, dealing with diverse cultures, a better educated workforce, longer term relationships, a mobile workforce, more consideraton of environmental factors, information security...

25 May 2009

Leading and change

Seth Godin talks about bringing change. You do that, don't you. An entertaining and interesting talk (sightly less than 20 minutes.)

23 May 2009

A description of an iterative requirements process

My team is using the scrum process.  The scrum manual labels the requirements manager role as a product owner.  In the context of a software house this is a simple enough role to fill.  You get the product manager to do the job. In an enterprise projectthere is a slight difference in how you'll need to tackle the role.

For one thing, an individual will rarely be given the authority to "own' the product. Secondly the needs of multiple stakeholders need to be addressed not just when the product rolls out, but every day the project is in progress as well.

This diagram is from about 6 months ago. It captures an iterative requirements elicitation and definition process. We've stuck pretty close to it over the last few months, but have made some improvements as we go.

In case you can't read the diagram, the steps are as follows.

Step 1; Weekly elicitation meeting.
Step 2; Developer & QA review of and initial estimating review of new requirements
Step 2a; Clarification
Step 3; Add to Product Backlog (in TFS)
Step 4; Introduce to sprint plan

What have we changed? We have elaborated each of the steps with some more detail and we have added some steps.

The new cycle is as follows

Day 1; Requirements workshop
Day 2;
Day 3; Initial estimating session with developer team members
Day 4;
Day 5;
Day 6; BA Backlog planning session
Day 7;
Day 8; QA requirements
Day 9;
Day 10; Sprint reiew, demo prouct

21 May 2009

Agile, Waterfall, Something else?

There are people arguing the agile case and there are people that deride it and say stick with the status quo of the waterfall method. There are people who say outsource everything you aren't an expert at.

I have yet to be convinced of any one way, but I have put together this matrix as a talking point. Right or wrong I would like feedback from people who know more than me.

Anyone want to start?

19 May 2009

Performance management

The five phases of a project (in the PMI context) are

1. Initiate
2. Plan
3. Monitor
4. Control
5. Close

Of course plan – monitor – control is an iterative process in itself. So maybe there are really three phases to a project; the beginning, middle and end. Like a story.

You are constantly correcting your plan in response to information you gather. You’ll then act on your modified plan to optimise performance, or minimise problems.

Here is my question;

Who’s job is it to implement the changes to the project plan and then to action them.

It appears on the face of it to be the project manager’s job, and at the detailed end it is. But first you have to gain approval to vary from your constraints – budget, time and scope.  Oterwise something else is going to suffer.

I am learning that in many projects the project manager does not have access to a sponsor or project owner who will or can engage in this decision making process.

What does the canny project manager do in this circumstance? Access your contingency until you get the conversation had? Press the matter with your sponsor or management (maybe using the squeaky wheel method)? Break the chain of command?

Or stand back and let it play out with an “I told you so” card ready for when the call finally comes to see the sponsor.  Can you pre-empt this situation by talking it out with the sponsor first? Not always.

Which approach is going to make the customer happiest? Which one will make them least annoyed?

What is your strategy?

While we are at it, here is this week's lecture notes on performance management.

Pic by YaniG, CC @ Flickr.

16 May 2009

Agile Adolph

And since it's the end of the week...

Thanks Kelly

15 May 2009

What problem?

"You know that stakeholder engagement problem you have?"

"Errr... no."

"Well, you need to keep a tight reign on communcations or things get out of hand"

"Ummm... What's out of hand?"

"People are worried about this project."

"Yep. I worry all the time.  It's my job.  I do things about it too."

"Well, lucky I'm here. Now everyting can settle down."

"Actually, things were kind of in control until you got here..."

- One of those weeks.

Picture by chanchan222CC @ Flickr

14 May 2009

Better Projects?

If you had to change three things about the way you work, what would they be?

13 May 2009

Managing conflict on projects

What I found most interesting in this content is the idea that problems that are left to fester get tangled up with other problems.

How do you tackle complex conflict?

One step at a time?

Your Bias

Kailash reiterates the importance of recognising your cognitive biases and how they may contribute to project failure (or success.) He analyses another article, including summary case studies of large failed projects.

What sort of biases are you guilty of applying to your project analysis, planning and management?  What systematic approaches can we apply to avoid cognitive bias that results in trouble?

A couple of suggestions from my experience;
  • Have your work reviewed by an experienced and independent advisor
  • Read an organisation's lessons learned
  • If you are on a project re-do, read the PIRs from previous attempts, or interview the survivors
  • Reflect on the difference between 'should have' and 'does have' in terms of capability and context

12 May 2009

angelo asks

Angelo asks some questions about how PMs think when dealing with team based troubles. Jurgen answers these questions at Noop.nl. And Soma repeats the question out for others to answer.

Well, readers, here is my perspective on my practices. Not that this is exactly what I do. Self awareness is a particularly hard state to achieve. (So, if you have worked with or observed me, I stand to be corrected.)

Q1. How do you select/choose the best possible candidate of your technical team? Do you have some sort of criteria / selection process which you may want to share?
In hiring a technical team I am looking for things like motivation and attitude. Professional skills like how you handle conflict and pressure, how you work in a team, do you have a structured approach to your personal work?

I refer to a technical specialist to assess technical skills. In the past I have encouraged some peers and friends to set test questions for interviews.

Q2. How do you ensure that each person on your project team is highly motivated?
I expect people to come motivated. If they don’t, I refer the issue to the team as something for them to sort out. I do my best to assist my team in personal interactions, but I can’t really solve all their personal issues. That’s up to them.

If it affects the team’s ability to deliver a product, that’s an issue for me and the team to work on collaboratively. Personally I tend to focus on positive feedback rather than disincentives. I would try to make the team work together effectively before dumping someone, for example. Opening communication and building trust is a useful technique.

In the best teams I have worked on the team genuinely like each other and so are willing to help each other out and to contribute so that everyone can be successful. Where teams don’t like each other, you work on getting people to understand each other. In intractable situations you can remove the problem people, based on team fit, or park them into non critical roles where they don’t have to interact with others.

Q3. How do you cope when one (or some) of your project(s) is/are getting way behind schedules and upper management is pinching you on the matter?
The main reasons for this are unreasonable expectations from the upper management, often based on poor communication from the PM or project leadership team. In this instance I try to shield my team from this political noise and deal with the misaligned expectations outside the team’s focus. Here is another area where a (leadership) team working together is critical.

If the frontrunners for poor performance are internal to the team there are two likely candidates; technical capability and team cohesion. You can augment technical skills with one or two highly skilled people (skilled in communication as well as technical skills) and you can train your staff. If the issue is team cohesion, that’s a tougher nut to crack. Revisit the team values formally as a group, identify problem areas and have the individuals come up with their own plans, and so on.

Bullying people into submission may work in some places, but I prefer to take a problem solving approach. You’ll need to get the problem identified, understood and acknowledged first.

Q4. How do you decide on the methodology with which to apply on your project?
Methodology is made up of 2 parts; what you need to do to deliver a good product, and what external people expect.

I suggest that you augment your team with a pair of process masters who can whip up any documentation as required for external stakeholders, and then as a team focus on what are the most important things you need to do to get your product to the client a fast and effectively as possible.

This does require some forethought, so a couple of days or sessions early in the project should be dedicated to bringing the team and key stakeholders together and discussing these issues.

Q5. Best advice (or something learned) ever from a person on your project team?
All project problems find their root in poor communication. Not all your stakeholders or team members want to communicate.

Pic by Sven CC @ Flickr

Wabi sabi

As I learn more about products, projects and management culture continues to reinforce it's place as the nexus of where things go right and wrong.

In an essay by Scott Berkun (Why Ugly Teams Win) I learn about the phrase Wabi-sabi.  A commenter on the post objects to Scott's definition of the term so I research further (starting here and then here.)

Wabi sabi...

Beautiful, but not perfect?  Or perfect because it's not perfectly beautiful?  A realisation that things change, they age, the evolve, and that something that is perfect today cannot be perfect tommorrow.

It's a different mindset from the one that usually surrounds me at work; "Strive for perfection at all costs.  We only have one shot at this."

Read up on wabi sabi, compare it to the philosophy where you work, and think about what it means for your product or project.

BA World presentation

I signed up for the Australian leg of the BA World/BA Symposium travelling conference. My topic is "The Business Analyst as Product Owner." 

I'm booked in to Sydney and Melbourne, so if you read this site, and are at the gig, drop by and let me know what you think. 

(Sydney and Melbourne dates are at the end of this post, along with a thank you note to a sponsor.)

Anyway, time is running out to prepare my content, so over the next fortnight I'll be working up some content with the intention of dumping lots of thoughts, trimming it into a sensible story, Powerpointing it and then talking about it.

Hmm. Did I just make up a word? Can Powerpoint become a verb?

Probably some of that content will be posted here. Your comments will help me, so thanks in advance.

The first question is why this topic?
My project life began with me as a BA, and I've swapped between PM and BA jobs off and on over the years. I have a fairly strong belief that good requirements management is the pathway to project success.

This last year I've been working with a team transitioning to scrum. It's been an interesting process and we've all learned a lot. Some of the learning has come from training, practice and reflection. Some of it has come from painful mistakes.

I figure sharing a few of these might help others going through a similar transition.

The second question; What is the audience looking for in a talk like this?
Well, your opinion is probably more useful than mine. (Hint; this is an opportunity to guide me via your comments.)  I am guessing that the audience will be mostly people in the process of learning and implementing scrum practices, and that there will be a few sceptics wanting to investigate from a distance.

More info on BA World dates behind these links;

Lastly, this will be one a few thank you notes to my sponsor for the Melbourne trip; Michael Augello if IGL, a consulting and IT agency that provide quality servies in Sydney, Mebourne and Canberra.  They are a great team to work with, and have been very helpful for me over the years.

Photo by hfb CC @ Flickr

10 May 2009

The Tao of Project Management

In the pursuit of learning, every day something is acquired.
In the pursuit of the Tao, every day something is dropped.

Less and less is done
Until non-action is achieved.
When nothing is done, nothing is left undone.

The world is ruled by letting things take their course.
It cannot be ruled by interfering.

Each week John Carroll posts another reflection at his blog The Tao of Project Management. Highly recommended.  Add it to your rss feeds today.

Picture by Miek37, CC @ Flickr

8 May 2009

Managing the development of large software systems

Where did this methodology discussion actually start?

Winston Royce wrote an article describing what he saw in the US DoD which became the kernal of the waterfall software development process. 

As Glen will tell you, the DoD has moved on and has gotten smarter.  It takes some organisations a while longer to catch up.  Especially while there are vendors out there peddling material hat steers you in the wrong directions.

Where did your organsation's project and software delivery methods come from?

Just like with detective stories and requirements analysis, my advice is: follow the money.

Picture by Snowshot, CC @ Flickr

Take a moment, take two...

Want to get more productive?  Stop and step out of the rush to get things done.  Reflect on the big picture.

"When we are relaxed, our brains are more flexible and more likely to find workarounds to difficult problems. In contrast, when we are frustrated and tense, our brains get a sort of tunnel vision where we only see the problem in front of us."

An article on design at A List Apart provides illumination on what could be going wrong at your job today. It also has some interesting stuff on the value of aesthetics in IT systems.

6 May 2009

INVEST in good user stories

A user story is a tool to articulate a business requirement.  THe model was initially defined by Mike Cohn.  It focuses on user goals, and it is designed to be discreet enough to fit into an iteration.  I've written a bit about them before.

Bill Wake came up with the INVEST model for breaking the stories down and modelling them in an optimal way.

4 May 2009

Occams razor & Specification

William was right.  We need to keep things simple.

Requirements documents have 2 purposes;
  1. Explain what capability is required 
  2. Describe the contraints that need to be adhered to
Whatever you can do to trim your documentation?  What are you saying that is unnecessary?  How can you use less words (and images) to deliver a clearer message?

Simplicity is the method.  Clarity is the goal.

Jonathan and Albert also agree.

Picture by alles-schlumpf, CC @ Flickr

2 May 2009


I suppose I should let you know that the ideas and opinions expressed here are not those of my employer or clients.

That goes for the spelling mistakes as well.

Here is an article on Telstra's social media policy. It sounds surprisingly reasonable, given that Telstra is one of Australia's largest (and thus bureacratic) companies.

(Actually, when I worked at Telstra I found them to be quite a dynamic and decentralised organisation. It was a pleasant surprise for me.)

If this disclaimer was disappointingly boring check these ones out.

Picture by whatnot, CC via Flickr

1 May 2009

EAC for everyone

Michael Hatfield of the PMI offers an EVM tool that doesn't require a WBA or baselined plan.

"The traditional formula for calculating an EAC (EAC = BAC/CPI) can be algebraically reduced to dividing cumulative actual costs by cumulative percent complete. That's right, we're talking two date elements, easily collected."

Check this out.

Do you use EAC in your PM status reports? If so, do you use this model?

Picture by hegarty_david,CC @ Flickr

The Better Projects Scrum Reading List


I am running a project using Scrum, and I have been discovering that even though the information is to hand many readers of traditional PM and BA sites aren't familiar with the process.  So I wanted to give an overview.

And once I started on that, it got out of hand and I have extended the overview into a list of all the things I think are important to know about when starting the agile/scrum journey.

Lastly the link titles don't always match the article headings at the other end.  It's a matter of context.

The Better Projects Scrum Reading List

The Basics
The advanced readings
Process milestones/ceremonies
The Roles
Requirements management
Release planning
Testing and quality
Scrum smells

Personal improvement
Implementing scrum 
  • Tips on implementing Scrum - for the team (Kelly Waters), for the client, for the stakeholders (Lynda Bourne, PMI)
  • Selling Scrum as a positive alternative
  • The challenge of Iterative requirements definition
  • Iterative and incremental product builds
  • The relational database and object base impedence (?)
  • Augmenting Scrum with XP
  • Lessons learned and shared, a year with scrum on Slideshare, Organisational change and scrum by Richard Banks
  • A Scrum book list is available here.
  • Online communties
If you'd like to offer any links, let me know in the comments.

(Picture by Gilmoth, CC @ Flickr)

Search This Blog