Search This Blog

30 June 2009

2 weeks of silence

I just checked my rss feed for Sydney project management jobs.  It's been quiet for the last 2 weeks.  Not a single pm job listed on Australia's leading job site.

Potentially there will be a flood of postings tomorrow, July 1, but it has been spookily quiet in the market.

In the meantime I just finished marking exams and loading up the scores on a borrowed computer.  Next task, get my machine fixed and get back to posting here.

25 June 2009

The role of the business analyst in Scrum

Shane Hastie writes an article for InfoQ on the role of an analyst on an agile team.  It is an excellent insight into the value a BA can bring - with some comments about behaviours and practices to avoid.
"There is a gap in much of the literature about Agile software development practices, and on many Agile teams. This gap is the role of Analysis in Agile projects - who does it, what is the use and value, and how does it change?
The implied (and I have heard stated at least once) attitude is "we don't need no stinkin' analysts" - needless to say I feel this is WRONG! In this article I make the case that the Business Analyst can play a useful in relation to Agile teamwork - when properly aligned with the business, rather than with the development team, as is too often the case."

24 June 2009

Self managed self motivated teams

The management literature point at self directed and self managing teams as an optimal management style.  It's also embedded into the agile and lean software development models I am familiar with.

This is where you want to go.  This is how you want to direct your organisation (or in our case teams.)  And virtually all workers have the capacity to get there.

But where is the pathway from here to there?  You are running a project with a deadline and plenty of constraints.  You need to set some goals for your team and you need to direct them in their tasks to keep them on target.  And you need to psuh them at the deadline, otherwise they'll go over time and budget, right?

Maybe, but sooner or later you'll want to switch across to the self directed mode of getting things done.

Small steps of leaps of faith?  Which one is right for you?

Picture by t3rmin4t0r, CC @ Flickr.

23 June 2009

The Professional BA

Kathleen Haas of Management Concepts deliverred this presentation last year.  Found on Slideshare care of Tom Humbarger.  It looks at a whole lot of stuff around defining the role and value of the busniess analyst. 

One particularly good features is a table defining competencies at various stages in your BA career.

19 June 2009

Testing sacred PM practices

Jeff Edwards carried out a survey of project managers, exploring some of the presumptions about project management practices. He has written up a series of blog posts on 9 PM areas and found only two of them had a really solid contribution to project success.

A caution on the study - it was of a limited size.  It is worth taking a look at.  Start the series here, and finish here, with a short podcast.

Seilevel's ROM

Seilevel have published a Requireents Object Model (ROM).  This is similar to a Requirements Entity Relationship (RER) model Guy Beauchamp put together in 2007. 
Compare the two and offer your thoughts.
Either model is an interesting choice. What do they give you?

One thing is a pathway to ensure you have good coverage of the requirements, another is to ensure you have good alignment to the sponsor/business goals.

18 June 2009

Email, Whiteboards and Well-Caffeinated Wits

This is a guest post by Jeff Hobbs.  Jeff is a project manager at ActiveState Software who provide pm and collaboration software.

Email, Whiteboards and Well-Caffeinated Wits

The culture of software development has many myths, but among its truths are that we’re a busy lot. Moving from project to project often has to happen so quickly that there’s little chance to take stock of what works and what doesn’t in the processes we follow and the tools we use.

That scenario probably feels familiar, but who hasn’t been eager to get started on the next great idea or the newest client with an almost impossible deadline that we’d love to meet? The love of making things and the pressure to keep moving can lead to some risky process decisions, especially surrounding the choice of project management tools. When ActiveState commissioned a survey to find out how developers are managing their projects, the extent of that risk and how far-reaching it is in the industry took us by surprise.

Our survey took in responses from a full range of software professionals, from one-person-shows to both small and large teams working across industries. Most respondents work directly in the IT industry, rather than in IT supporting another industry, and some 66% work in teams of under 10 people.

The first surprise was that only some 14% of respondents are using a dedicated project management solution. Surprising but not a bombshell by any stretch, because we know that specialized tools that can be used in tandem if there’s a process that stitches those tools together. Only some 20% of respondents are using those specialized tools to assemble their own ad-hoc project management system.

That leaves some 80% using little more than email, whiteboards and well-caffeinated wits to keep track of all the things that need tracking in a technology project. That number really surprises us, partly because we all know there are established names in project management solutions. But let’s face it: where mindshare isn’t translating into market share, something isn’t working.

The climb from barely organized to really getting things done as a team can look daunting from the bottom. But some small first steps and tips for thinking about the process of selecting methods and tools can make it easy to get under way.

Set Your Sights
Make a simple statement of the project goal, then print it out at a size that you can read from across the room and post it wherever work is happening, online or in a physical space. Having that common goal present in the team’s working context is a visible reminder of what’s most important, and a great touchstone for testing new ideas and decisions along the way.

The Real Team Energizer
Forget Red Bull, and throw out the Jolt. The thing that will really energize your team is making information critical to the project easily available to everyone in the project. With feature lists, discussions, schedule milestones and key decisions taken along the way, you’ll find the need to remind and re-hash established knowledge going way down. One thing that can be hard about opening up the flow of information in a project is stopping the email habit. Email is easy, but it can be a project killer by locking up crucial data in the recipient list. With a commonly-accessible store of project information, the walls between team members that we may not even see come down.

Don’t Rush into Commitment
Choose the tools that demand the least up-front effort to start using. Diving into a project management solution that requires hours of setup can give you a feeling of getting things under control, until you find that it just doesn’t work the way your team works. Choosing a tool that lets you start with a low commitment of time and effort, and that can grow as you find it more useful, will avoid wasting time on dead-ends that might be good for other teams, but not yours.

Ask Around
Talk to other software teams and find out how they keep themselves on track. If you’re already in a community that you like talking with, bring to them the question of how to evolve the way a team works. Pitch an ad-hoc discussion over drinks with some local developers working in teams of a size and nature similar to yours. Even if you don’t get the exact answers you need, it can feel good knowing you’re not alone in facing project management challenges. And you might make some new friends in the process, as a bonus.

Whatever course you choose, if you’re not using a project management process that’s working for your team today, the one thing that I can guarantee is that it won’t get better without making a change. And like crossing any distance, taking that first step gets you that much closer to project sanity than you were before.

17 June 2009

If communication is so important...

If communication is so important, what are the standard ways we measure it?

I am reading and marking essays.  One of the great things about this process is reading perspectives on project management from informed outsiders.  It's really interesting hearing other people's take on my job.

Take this comment from an essay; "Project managers always say how important communication is.  But how is communication measured?"

Yes, you have a plan, and yes you track whether things are done on time and to budget. 

But how do you measure the effectiveness of your project communciations?  And how do you make sure the activities remain aligned to the project goals?

Photo by  woodleywonderworks CC @ Flickr.

16 June 2009

Business analysis and SCRUM(!) development

Enterprise projects require more than just knowing what features are the next most important ones to deploy.  Business analysts remain critical in enabling everyone to be heard and in balancing competing views, but as it stands today they usually don't have the authority required to pull off the Product Owner role.

Business analysis and SCRUM development by Rochelle Glover explores what existing project roles could act as a scrum Product Owner.  (The comments after the post are also interesting.)

Found via JB's Practical Analyst.

15 June 2009

Business Analysts and Project Managers: chalk and cheese?

See Elizabeth Harrin, author of A Girl’s Guide to Project Management and is the author of Project Management in the Real World at the IRM UK Business Analysis conference in London on 29 September.

Business Analysts and Project Managers: chalk and cheese?

Business analysts and project managers often find themselves working together on projects, and not always with great results. Project managers and business analysts don’t always see eye to eye, and this leads to conflicts on the project team. It’s not always about a clash of personalities; it’s more often just different approaches to working, different goals and different methodologies.

Elizabeth Harrin will be tackling these differences in a presentation at the IRM UK Business Analysis conference in London on 29 September. “I'll be talking about how project managers and business analysts attack the same topic from different angles and addressing how to work effectively together,” she says. Drawing on her own experience as a project and programme manager – and from a brief spell working as a business change analyst herself – she’ll discuss why project managers don’t intrinsically value business analysis and to avoid a “them and us” attitude.

This presentation will provide a real insight into what project managers think about business analysts and how BAs can use this to their advantage to drive home successful solutions.

“I think there’s a long history of tension between the BA and PM communities,” Elizabeth says. “It’s because both sides bring something different to the table and don’t understand the value of what the other party brings. I don’t think we talk about it enough, so I’m looking forward to opening up the debate.”

The conference runs from 28-30 September 2009. Full details and the programme are available online. IIBA and BCS members are entitled to discount on the conference fees.

13 June 2009

BCS forum on "Making Projects Work"

You've heard many reasons why project fail.  Here is a discussion hosted by BCS on why projects work.

The discussion covers four dimensions of projects;
  1. Project Change and Perceptions of Failure
  2. Personnel in the Project
  3. Is project management over-complicated?
  4. Achieving project success

10 June 2009

Kano requirements talk at ACS

I am speaking to the ACS requirements SIG on 25th June on using Kano Analysis for requirements prioritisation.

(Details of event are here)

(Apart from being a distinguished professor and recipient of the Deming award Kano is a bad guy in Mortal Kombat.)

9 June 2009

Your age is not as important as

...the age of your client.

However the gap between your age and your clients is important.  Think about it for a moment.

A person's age is one of a number of visible cues you can use to assess whether they are culturally aligned with you.

If you are an inner city 25 year old payrolled web designer you are going to start your thinking at a different place to a 62 year old rural business owner.

Picture by Freyja* CC @ Flickr.

6 June 2009

The man from F.I.S.T.

Sounds like a James Bond bad guy, right?

Well, care of a comment on this blog I rediscoverred a pm writer I used to follow a few years ago at the Rogue Project Leader.  Dan has dusted off his PM writing cap and has kicked off another series of articles, this time in blog format here.

I have not delved into the current artiles yet, but did enjoy the originals.  I wonder if they have aged well?  Probably.  Most management lessons never get learned well.

And F.I.S.T?

Dan's recipe for success is Fast, Inexpensive, Simple and Tiny.

That sounds sooo right.

Rogue Project Leader
Pic is from  bruckerrlb, CC @ Flickr

4 June 2009

Resources for new business analysts

When you are taking on a new role you can often be overwhelmed by the things you don't know; How much detail is enough? Have I got all the right stakeholders on board? How would others see this problem?

The bext thing you can do is ask your peers and customers. A good conversation is the best thing tere is for clearing up uncertainty and generally experienced people like to share their knowledge.
In some organisations it gets a bit trickier. Maybe there are not many analysts around to ask.

Maybe there are few or no structured projects and so few experts to go to. Maybe the clients don't know what they want. Or maybe you disagree with the way things are done and want to validate your opinions.

To that end I want to provide a list of online resources; places you can go and read or discuss business analysis and all it's specialist features.




  • RQNG does a good one.
  • B2T Training have a quarterly newletter called "the Bridge"
  • (You could also sign up for the feedburner weekly email for this site)

There are many quality blogs.  I'll have to do a separate post just on them.

Let me know if you know of more useful sites and resources and I'll add them onto this post.

3 June 2009

Scrum Product Owner training

Good requirements management is a critical part of the project succes story and this applies no less to agile or scrum projects that to any other project method.

Two agile trainers and consultants are offering training in requirements management in the context of scrum. (BTW I get no reward or kickbacks from these guys for this promotion.)

North America
Alistair Cockburn offers his next Scrum Product Owner course on 1-2 July.
"Learn a simplified view of the underlying theory that allows an agile approach to product management to get products to market faster, bring revenue in sooner, and tune the product to the market needs more quickly. This course is designed to fit with the Scrum methodology, so that product managers who have to interface with Scrum development teams can understand what to expect from the team and what is expected of them. Completing this course will allow you to get the Certified Scrum Product Owner certificate. For those who not interfacing with Scrum teams, the same techniques and thinking will assist in your conversations with your own development teams."

Rowan Bunning offers a Certified Scrum Product Owner course on 15th - 16th July in Sydney.  (See Rowna's whole schedule here.)

Content of Rowan's course;

  1. The Scrum Framework - Positioning Scrum, Activities, Roles, Artifacts
  2. Agile Thinking - Agile Values, 'All-at-once' Development, Timeboxing, Empirical Process Control
  3. The Product Owner Role
  4. Visioning
  5. Agile Requirements Management - Role Modelling, User Stories, Non-functional Requirements
  6. Product Backlog Management - Grooming the Product Backlog, Splitting Stories
  7. Prioritisation - Value Creation, Prioritisation Techniques
  8. Agile Planning - Release Planning, Sprint Planning
  9. Product Review - "Done" and "Undone", Acceptance Testing, Sprint Review
  10. Product Management - Stakeholder Management, Release Management, Plans, Status, Indicators
Picture by Don Solo and CC @ Flickr.

2 June 2009

Fundamentals of Requirements Management

Ivar Jacobsen has proclaimed an end to methodology wars. It has me thinking about one particular part of the puzzle; managing requirements.

Fitting everything into the available time and resources is a major and constant struggle. Even when you spend months planning you still run into unintended features – things you have to build but didn’t plan to.

What helps deal with this?

Firstly a requirements manager who deeply knows and understands the client problem, and that has the trust of the client and sufficient authority to make a call on what is in or out of the product - at release 1 and at the end of the project. (See CRACK requirements)

Secondly, the ability to chunk (partition?) the work into multiple releases.  This addresses the need to deliver complete and coherent capabilities.

Need to capture a reciept number?  Sure thing, but do you have a free text field or do you integrate to the payments system?  The choice depends on time and money and competing priorities.  Both solutions are 'complete' in their own context.

Thirdly sufficient communication (and leeway) between the requirements manager and the developer team so that innovation can overcome some of the financial and schedule constraints, and so that develoeprs aren't left guessing what the right scope or success criteria are for a particular feature (see the above example.)

What else is core to successful requirements management?

Photo is from flickr

Contemporary Issues lecture

Part of the course I teach includes a reflection on contemporary issues in project management.

The course content comes from Gray and Larson's "Project Manageent; The managerial process" (2006.)

It's view is more strategic that the methodology business going on in blogs an forums. This one is a short deck; only 66 pages, which should take just a few minutes.

1 June 2009

Project management artefacts and the emotions they evoke by Stephen Jon Whitty

K reviews another Whitty article at 8 till late.
What did I get from it?  11 topics to explore further;
  1. Project
  2. Deadline
  3. Team
  4. Professional persona of a project manager
  5. Gantt Chart
  6. WBS
  7. Iron Triangle
  8. S-Curve
  9. Project management post-nominals (certifications, degrees, titles)
  10. PMBOK Guide & Project management methodologies
  11. Professional bodies

Whitty's paper suggests that each of these topics generate an emotional response in project managers. Presumably the same goes for most people on the project team, and they key stakeholders as well.

Picture by nrvica CC @ Flickr