31 October 2008

Onion rings

Further expanding on my point from the other day - aligning requirements to the organsiation's goals isn't that hard.  All it takes is an understanding of the big picture.

It never fails to amaze me how many IT team members, particularly programmers and DBAs don't actually get the big picture.  How do they know if what they are building is helpful or not?  How can they stop and assess requirements and look beyond them to see if there are better ideas able to be implemented?

Of course many are across the whole thing and do a great job of delivering value.

Help the others out by being clear about how your view of an IT product contributes to the organsiation.

As you develop a set of requirements, come in top down, starting from the business goals or startegy and work your way down to the details.

Is anyone not doing this these days?  If so - can you share a story about whether it's working or not working for you?

29 October 2008

Two useful techniques for requirements and project briefs

I was just reading a handful of project briefs (or project scope docs) and noticed a pattern I wanted to share.

I am reading these briefs to assess whether projects have been successfully delivered or not. What I found is that some project briefs are better aligned to high-level business goals and it is the same ones that are best articulated so I can see whether a project has been successful or not.

The techniques that have been most helpful to me are:
  1. A clear alignment from top to bottom of goals to activities,
  2. A consistent use of phrases that are easy to identify as done or not done
The first technique – aligning the technology to business is a massive issue in (not just our) industry today, and sloppy analysis and design work is as much a part of the problem as no analysis and design. Possibly more. (http://leansoftwareengineering.com/ksse/scrum-ban/)

This second technique ties in with the idea that everything from requirements to units of code should be testable in a very black and white – binary – way. This idea is encapsulated in the test centric V-model of software development, agile's test driven development and other methods and ideas. Everyone agrees that testable requirements and solutions are a key success factor.

Why then are professional, educated analysts failing to deliver testable requirements? One hunch I have is that everyone is too rushed to accommodate a peer review of requirement specs.

Well people, the industry numbers are inpeer review of requirements cuts defects massively. The time you invest today will save a large swathe of time in the future when the solution is reworked to cover the gaps and holes left by poor requirements.
Photo by snapperwolf* cc @ Flickr

27 October 2008

Can Agile (Scrum and XP) work for large projects?

Some people say no way!  They say 'Agile is about small and tactical solutions.  The lack of up front planning precludes highly complex solutions.'

Some people say, hell yes.  The process is very scalable, but it takes practice.  You'll make mistakes before you get it right.

Check out this 90 minute video and slide presentation if you want to go deeper into this topic.

24 October 2008

Business Model Innovation

Alex Osterwalder has a great framework for analysing business models, and some great presentations online to help you work through his ideas.  This is one of them.

It is at the strategic end of the project process, and thinking through this stuff will help ensure business and IT alignment.  That's something we could do more of.

23 October 2008

Strategy and business

Thinking out loud today...

Businesses have strategies, and staying aligned to startegy is supposed to be a sensible thing.  It helps maximise the effort spent on the strategic goals and targets.  And the more effort is expended the more likely the goals will be achieved.

Often strategy is about transporting you into the future.  So the goals are described in terms of where we will be in 3, 5 or 10 years.  And yes, projects are the main vessels that take us there.

Does this mean all strategic initiatives should be deliverred through projects?  No, I don't think so, although many of the non project initiatives could well be projectized.  Think for example of a change in culture as a strategic initiative (e.g. "We want to become a more family friendly workplace.")

The actual change in culture might not come with a project, and while projects may help enable it, they may not be forthcoming.

And does it mean all projects are strategic in nature? Nope.

They aren't even all aligned with strategy (although they should be.)  Some projects are very down in the detail of an organisation.  How, for example, do you align an office fitout with a startegic imperative?  Some things are just maintenance work.

But are there projects that are of a strategic scale that are not aligned to organsiational strategy?  Yes, there are plenty.  How do they do?  Not so sure.


22 October 2008

Technical vs. non-technical PM redux

I am always fascinated by the ongoing debate of which is better, the technical or non-technical Business Analyst or Project Manager. That's why I just had to let you all know about this article by Tom L. Barnett, PMP over on gantthead.com. It's an excellent addition to the discussion that I think really captures why it is such a difficult topic to resolve.

You can find examples of success on both sides of the argument as well as examples of failure. Mr. Barnett takes a closer look at two examples and in my opinion makes a compelling case for his conclusion. It's about the people, not the process or the domain.

What do you think?

21 October 2008

Continous improvement for project professionals?

Two broad questions for you and your colleagues.

What are you doing to improve your skills?

What is your industry doing to improve it’s overall performance?

On the later question there does indeed seem to be much activity. But ask yourself this; will this activity help you do your job better? And if not, what improvement actions are you taking?

Picture care of Okinawa Soba, CC and Flickr.

19 October 2008

The Project Management Process # 11- Contemporary Issues

This is the end of this series of Project Management presentations.

It covers the ephemeral topic of 'contemporary issues' and is deliverred to masters students in the mid 20's so don't expect the sort of discussions we usually have around here (although agile makes an uncredited walk on in there somewhere.)

This series was based upon the textbook “The Project Management Process” by Gray and Larson, referenced in the first few pages of most of the slide packs.

It’s a little dated, especially as it assumes a waterfall development framework. However most of this content is about the social and interpersonal aspects of project management, which are agnostic of pm processes and frameworks. So it still delivers pertinent and relevant messages. Go read it.

Your feedback is the main reason I provide my content online for free. So if you read and like, dislike or even hate the content I have provided, it would be great to hear from you.

Thanks for reading along.

18 October 2008

Are they the right features?

Let's put aside all scepticism for a moment and say Scrum does deliver features faster and more reliably and defect free than most other project methods for a moment.

Are they the right features?

It's like that idea of doing the thing right, versus doing the right thing.

The mechanism in scrum is to ask a product owner what to do next. Not much seems to be written about how the Product Owner goeas about this task.

For complex enterprises facing complex problems I expect some deep thinking has to happen first.

Requirements may trickle into the tech team, but a big picture - maybe a business architecture - view needs to be established.

And then there is the change management aspect to consider. Training, getting people to adopt the change, scheduling other changes among system releases etc can also be a complex activity.

Your thoughts?

Picture CC, by darkmatter@ Flickr

17 October 2008

Understanding projects

Executives and CEOs around the globe want to know why projects cost so much and so often let them own by deliverring poor outcomes and going over budget and over time.

It's an issue worth exploring. Even though we as practitioners are vaguely aware of where the project's key risk and failure points are, business sponsors and stakeholders continue to be disappointed.

What are you doing, or have you done to ehlp your non project professionals work with your team?

15 October 2008

The 8th Habit

Stephen Covey has contributed a lot over the years to people in general, but his advice has often been particularly pertinent to us project workers, who have a particularly challenging role - implementing change effectively.

Raven plugged the 7 Habits, plus the 8th Habit audiobook at her blog last week.  I know the 7 habits.  I've even read the book.  But I had not botherred to discover the 8th habit.  So, following her post I looked it up.

And guess what.  It's a call to start blogging.  Or at least something along those lines.

Covey says "This 8th Habit is to Find Your Voice and Inspire Others to Find Theirs."

Blogging does that. So does leadership at work and in your community, and so does helping others, and learning in groups, and sharing knowledge and experiences.  And so on.

Picture by Leo Reynolds, CC @ Flickr

13 October 2008

Information, decision rights and effective project management

HBR's article on Strategy Execution (Neilson et al, June 08) talks about the relative effectiveness of various strategic approaches to change and finds information flows and decision rights to be the key areas to address.

Let's take a quick look at how this principle has been applied in project management.

Firstly we have the issue of responsibility.  This is linked to definitions of success.

I often suggest here that poor project leaders call success delivering to contract while excellent project leaders deliver outcomes that make their customers happy.  Life isn't as simple as that, but this idea can help you work out what boundaries you should set for yourself around your responsibilities and authorities.

In most instances  project leaders are expetcted to make a few waves as they deliver their project.  Breaking conventions and lines of command is often acceptable.

You as the project leader have to be willing to make these waves though.  And even though others may have a different idea of where your boundaries are, you should know that your boundaries are linked to whatever it is goiung to take to deliver the project results (ethically and sensibly.)

So you are going to need to take responsibility for project outcomes, not processes.

This means that you will need to seek out the appropriate information to make good decisions.  In many organsiations information is only traded for something of value or even kept secret.  You need to overcome these barriers using your team and the project mangager's toolkit (check the the social, cultural and political sections.)

Don't wait for information to come to you.  Go get it.

And thirdly there is enabling your team.  You need to give them the room and authority to make decicions appropriate to the problems and opportunities taht are going to present themselevs along the way.  If you can hand over decicion making at this level your whole team will increase quality, velocity and motivation. If you can do this, everyone wins.

Go check out the article if you want the broader view, or feel free to comment on my thoughts above.

Picture by njscott-H :), CC @ Flickr.

11 October 2008

The Project Management Process # 10 - Managing Global Projects

This is a wide ranging presentation touching on a number of issues, from dealing with vendors to working oveseas.

9 October 2008

Buiness Analysts and the English Language

Earlier this year an Australian academic produced a report claiming that verbal communication skills are the greatest barrier to non English speakers practicing in the area they are trained in.

In the workplaces of most corporations' IT and project departments in Australia there is a strongly multicultural workforce. People typically do not mind having to deal with thick accents and are happy to help their peers if they have particular challenges with the language. People, at a day to day human interaction level, generally want to help you do well. It's the hiring process that provides the biggest challenge.

And of course the best way to overcome your concerns about your communication skills are to (a) practice, and (b) realise that you are probably much better than you think.

Follow Larimar's advice and check out Toastmasters. The features they can provide are opportunities to practice public speaking, and will even video or tape your speaking - which is a great way to hear what you really sound like (and generally we all hate hearing ourselves the first time.)

Lastly; in the workplace; don't fear asking questions. It is your job and people will respect you if you ask. After all, it will be the unasked questions that cause the project to fail.

8 October 2008

Reliable (RATER revisited)

One of the core attributes of success defined in the RATER quality framework is reliability.

In a previous post I described reliability as a combination of availability, consistency and you taking personal responsibility for outcomes.

Today I read Hal's post at the PM Student expanding the topic further (care of HBR.)  The post has 5 elements and 5 characteristics of reliability, and is in the context of delivering on promises.

Go read the article for the full briefing.

Here I wanted to capture the 5 elements of reliability for completeness on the RATER topic.  They are;
  • Competence
  • Effective pre-work estimation
  • Allocation of capacity
  • Responsibility, and
  • Sincerity
 These topics will resonate with experienced project managers and business analysts.  For the moment thyis is a bookmark for myself.  I hope to expand on the topics in the near future.

7 October 2008

Consulting and goal alignment

Conflict within and across project teams is on my mind. Here are some thoughts that just flowed out of my fingers into Powerpoint.

Goal alignment is a key attribute for a successful project. If people are not working for the same goals you have no chance. And usually, everybody says they are all working for the one aligned goal.

And often, the truth is not so clear cut.

6 October 2008

To all the PM Students

Dear students,

Bas de Baar asked me what it was that I hope you take home from my classes.

Of course I want you to take away knowledge that will get you through an exam and into the workforce.  But I also want you to take something else away.

And that is the awareness that book knowledge, and even real world experience is worth very little compared to a passion and interest in what you are doing.

If you are (or have been) sitting through a pm class because it is a mandatory subject, and what you really want to do is code I hope learning about project management helps you understand the stakehodlers, customers and context of the work you are doing, and that as a result you are able to do better work.

If you are actually interested in learning about managing projects and want to do it for a job/career, then I want you to realise that the technical skills, while important, are only part of the picture.  And that it is crucial to understand people, "their goals and aspirations" and all the social, political and cultural issues that get in the way of doing good work.

In the PM classes I deliver I just mention this as an aside from time to time, but I do raise it consistently, and hope that it settles into your brain, so that one day, a few years from now, you realise that you need to put down the gannt chart and pick up the phone, go visit someone or otherwise act to improve the relationship you have with your project stakeholders.

Good luck with it.  Project management is hard, weird and exhausting.  But it can also be very rewarding.

Now, having said that, as a motivated and enthusiastic PM student, you should go over to the PMStudent website and register so you can start bogging about your learnings, reflections and experiences.  It will help you by making you reflect and structure your thoughst, and it helps others learn from your experiencs.  It's a great process for everybody involved.

Link: PM Student (and author registration page)

4 October 2008

The Project Management Process # 9 - Performance Management

This week's topic is mainly about Earned Value Management, but also includes the broader issues of why you need to track and report on progress against your project plan.

3 October 2008


Let’s say you are efficient and skilled.  Let’s also say it takes you 6 weeks to collect and lock down your project requirements. What do you do if you only have 3 weeks?  And on top of that you are new to the organisation and need a week to get settled in and learn who is who and what is what.

What do you do?

Your sponsor wants the new product launched, and wisely they are not pushing you to go live before you are ready.  Your sponsor is lo wisely not pressing for the Rolls Royce edition of the product.  They just want a basic serviceable product that they can put in their next quarter’s advertising and promotion plan.

But one of your stakeholders has put up a mandatory requirement that forces you to build the Rolls Royce solution.  And it’s not just some minor player in the business politics.  It’s the information security people who present a report each month showing how much data theft is going on and how much money is quietly being stolen.

What do you do?

Photo by LunaDiRimmel @ flickr

2 October 2008

7 Requirements Analysis techniques

In one of the Carnivals of Business Analysts the theme was “Requirements Analysis."

I searched the web far and wide and came up with a number of blog posts and articles on Requirements Analysis.  I felt that it missed something practical and directly on how to analyse the requirements you have gone out and collected, After all, if you are just going and collecting information and then passing it onto the development team you are a waiter, not a business analyst.

The most trying projects are those where the business plays the role of solutions architect, and the BA plays the role of “waiter”. - Jonathan Babcock

So I wrote an article myself highlighting seven analysis techniques that can be applied to requirements.  You’ll analyse and apply attributes to them between getting them raw off the business and handing the to the solutions team.

Many of these techniques will be familiar to you.  A few may be new to you.  All have been around for several years.  You might find some of my assessments and comments vague, incomplete or wrong.  If you do, can you be a good stakeholder and let me know what you think I should do to improve things?

The full article is here.