28 April 2007

Fred Brooks: The Mythical Man-Month

Question: How does a large software project get to be one year late?

Answer: One day at a time.

In 1975 Professor Fred Brooks wrote a book called the Mythical Man Month which was full of good ideas and observations on how to successfully blow a project schedule and budget out.

His basic observations were about the increase in complexity and the importance of communication as the number of people on the project increases. Eventualy you'll have so many people that the work becomes too complex.

Are his observations from 1975 on software project management still relevant in today's agile/ mega-project infatuated world? You be the judge.

Update 26 Sept 2007 - Mike Ramm points us to a book review on the Mythical Man Month. You can read it here.



25 April 2007

Four views on project success

I have skimmed the topic of project success a few times but have never got into the meat of the topic.

Here I am framing some thoughts I have about what constitutes success for project workers like you and me.

I am very interested in comments on this topic so please - have your say.

Project Success
The CHAOS report is quoted often as saying IT projects in particular are unlikely to be satisfactory in the vast majority of cases. Many projects exceed budgets and timeframes and/or fail to deliver on the requirements. Does this mean they have failed?

I have written a series of posts on internal marketing which discusses the importance of marketing to users, stakeholders and the client to help make a project acceptable and indeed perceived as successful. This series mentions a number of success criteria beyon time-cost-quality including user and stakeholder satisfaction.

Product Success
Max Wideman, Project Management guru, has also written an article called Selling into Project Success where he talks about the difference between product success and project success, and how at the end of the day of he product fails, so has the project. As a result of this relationship he suggests you need to factor in the marketing and selling costs of the project.

Project Management Success
Upon further reflection there is the idea that projects can be run without project management. A business can throw people and money at a problem until it is beaten. If a project manager is brought in to the mix the number of people and the amount of money spent will be reduced. That doesn’t mean that the project comes in at the estimated deadline and budget – but it could still be called a success.

So I now have three views of success;
  • Product success,
  • Project success and
  • Project management success.

Each of these three aspects will shape what is perceived as true success by the people that count – the ones with the money and more work for you in the future.

Perceived success
And so a fourth view - and a more pragmatic one: My beliefs about success are centred on the client’s satisfaction after the event. Were the clients left happy? Would they hire you again? Will they refer others to you? I think these are the best indicators of success.

What do you think?

RATER: Table of contents

RATER table of contents

RATER is a service quality framework. It helps service providers focus on what is important to customers. As project workers are basically providing a service to clients I thought it is a useful framework to reflect on in the context of project management. I believe that quality service delivery is closely linked to project success.

I am interested in people's thoughts on this topic. If you would like to contribute to the discussion please leave a comment.

RATER: Responsiveness

Responsiveness is the last of the categories in the RATER framework.

The first thing you think of when you reflect on responsiveness is usually speed of response. That’s what is usually meant when talking about IT systems responsiveness and quickly responding to a client or stake holder’s requests is an important part of this attribute.

Call centres recognize the importance of answering the customer call as quickly as possible, and it is usually one of the most important metrics in any service oriented customer contact environment.

Professional consultants and service providers are also very aware of the importance of a quick response. People are coached to return emails and calls on the same or next working day, and to keep people informed of what is happening as work is in progress.

There is more to responsiveness than a quick reply though. How many times have you been questioned or challenged about a decision you have made, and your first response is to justify or explain what you have done?

I’ll give an example from my work life; when I was writing more specifications documents I would have to present the specs to stakeholders and various project participants to get the document approved for the next stage of the project. My usual method was a combination of group and individual presentations/walkthroughs after many hours of investigation and careful thought.

Naturally no-one else has thought about the specifications as broadly or deeply as me, the business analyst, and so it would be frustrating to have to deal with challenges. But each person’s feedback was important in two ways; firstly it would check that my assumptions and analysis was rigorous, and secondly it allowed the other project participants and stakeholders to be heard and to engage with the project.

I had to suppress my instincts to instantly explain why I had made certain decisions or described things in a certain way and instead listen and acknowledge what the person was saying to me and look at how it could be a contribution to the project. This doesn’t mean an endless cycle of document revisions. It simply meant listening and talking with the stake holders about their issues. It was taking their feedback “onboard” for want of a better cliché.

My example is provided to illustrate that responsiveness goes beyond being quick. It has to be an appropriate response to the interaction. It includes acknowledging the other person’s idea or request, and engaging with them before providing your response.

It helps to think about the people you are interacting with as collaborators on a problem. They are helping you tease out the subtleties or complexities of a problem which will,. In the end, enable you to deliver a better solution.

23 April 2007

RATER: Empathy

Rick Freedman writes a book about the way consultant manage their clients. In the introduction he highlights the fact that a client’s preference for working with certain people can hold up projects until the right person is available even though other, equally qualified people are ready and waiting to do the work.

Similarly patients will also cross the city to visit their preferred GP. Patients are not in a good position to assess the quality of medical advice they receive, so what makes them care enough about a doctor to make such efforts? The answer is the “bedside manner” which in the context of this article is their empathy.

Technical ability is table stakes. What sets you apart is the way you deal with your clients. Empathy comes from listening and understanding. Empathy is being able to put yourself in the customer’s shoes.

For project workers who are managing change into organisations or developing new products or systems a customer includes the sponsor, users and all the stakeholders who have an influence on your project. That makes the job of the project manager and business analyst complex and difficult.

The payoff is that you have taken more time and effort to understand your clients and stakeholders and so your understanding of their needs and wants is better. You’ll be better able to interpret requirements and manage their expectations. You’ll also be a more trusted advisor and get more and better work with that client in the future.

Empathy requires that you listen to the people around you. It also requires that you listen to yourself – your own instincts and hunches. As busy people you need to build space in your week to reflect and to reflect on what has been going on around you and to work out what the real priorities are and what needs to be done about them.

“Better leaders and better managers are, above all, better listeners -- to others but also to themselves.”

You can read more about managing empathy into your work life at Mulhauser consulting here.

18 April 2007

RATER: Tangibles

Tangibles are physical things that people can interact with. Usually this means they are physical things you can touch and feel. In the service oriented consulting world of the project manager and business analyst tangibles are an important part of satisfying your clients.

Delivering tangibles improves the service experience for the customer. People have a hard time assessing non-tangible things like service and as a result they tend to measure the mistakes rather than the successes. You can help them appreciate your successes by giving them tangible objects to work with. This helps them engage with you, your project and the ideas you are trying to convey more effectively.

Look to the advertising industry for a good example. They understand the way a quality bound document will influence a client’s perceptions and they deliver quality tangibles in an intangible industry. An easy to access example is the Lovemarks book by Saatchi and Saatchi CEO Kevin Andrews. The books design is part of the tangible experience that delivers it’s ideas.

Quality documents
Like advertising, in projects the most common tangibles are documents and reports. Use the colour printer, go to the local print shop and make a glossy brochure for your project. Make your documents punchy and to the point. Try not to deliver another 80 page document that won’t be read – but if you do have to use large documents make ample use of colour diagrams and graphs to visually represent ideas. Have a colour title page.

Rather than email large documents to people deliver the bound physical copy to their desks. They will appreciate the easing of their email burden and the document will be better digested in paper format. You’ll also be able to ensure people get your snazzy colour pictures rather than print them in black and white.

Take your time on the layout and design of documents and don’t rely on off the shelf templates. Learn your audiences quirks and needs and tailer your documents to them.

Prototypes and early designs
For software projects tangibles can be prototypes and samples or screenshots of user interfaces. In business process projects tangibles can be pilot processes demonstrating the FMO model in action.

Tangible Business Cases
Money in the bank is also a tangible. In the commercial world money in the bank may well be one of the most important tangibles. Business cases should always deliver tangible benefits. Systems like Six Sigma can help you identify those benefits. We can discuss business cases and modelling in another post, but make sure your project is going to provide a measurable financial benefit and that you deliver that benefit.

Too many projects have weak business cases and then when costs blow out they are likely not delivering any benefit back to the business.

17 April 2007

RATER: Assurance

Do you have the right knowledge and skills to deliver the service you promised? Do you show respect for your customers? Do you convey trust and confidence?

Assurance is about inspiring trust and confidence in your clients and customers. It is all about making people comfortable with you and your work. You can do this through demonstrating knowledge and courtesy in your interactions with your client, the project team and stakeholders and your suppliers.

Everybody talks to each other and the more people you can have saying positive things about you and your work, the more trust and assurance you will build. You want that trust and assurance so you can get on with the job and so you can run your projects with less interference.

I say trust and assurance because you build assurance through trust. You can get that trust through referrals from third parties and through the way you interact with people.

When you buy a car you take it to a mechanic you trust to check it first. When you sign on to a new mobile phone deal you ask your friends which deal is best. You are taking guidance from people you trust and that trust is then placed into the company that’s providing new thing you are buying

You can also build trust by the way you interact with your colleagues and clients. You can do this by showing up on time, doing a good job and pitching in to help others. Take a proactive approach to your work and the people you work with; whenever you can go the extra few steps that leave people impressed.

Demonstrating a good service ethic is really useful in developing trust at the workplace and getting others to vouch for your reliability. Enlist the people you work with to become your advocates. A referral from a trusted source is your pathway to building assurance.

Deliver on your promises. Leave a trail of happy clients.

11 April 2007

RATER: Reliability

McDonalds’s iconic Big Mac is all about the reliable same burger wherever you are in the world. Reliability is important when you pick and ISP. A recent survey found that consumers rated it the most important feature by far, over everything else including price. You want your doctor to be reliable. You want you car to be reliable.

Toyota don’t make it their mission to build sexy cars, but their reliability makes it the leading car brand in the world. The Camry has been said to be the most bring car in the world but it’s reliability makes it the number 1 seller in the US.

“You don't build a reputation on what you're going to do.”
- Henry Ford

To demonstrate reliability you need to show people what you can do. As a PM or BA you need to find ways to demonstrate reliability. If you are a full time member of the business you build up a reputation over time for delivery and doing what you say you will. If you are only here for one project (i.e. you are a contractor or a vendor) you need to find opportunities to deliver small victories along the way towards your project’s outcome.

The Business Analyst has a particular challenge as they don’t typically lead projects, but work on them in a supporting role. The BA does have the opportunity to advocate the needs of the business to the project and manage the business’ expectations to the degree that they are satisfied with project outcomes. They can also add value in other ways – and be seen to do it.

You can show reliability through availability, responsibility and consistency:

  • You are available every time you are supposed to be – you are not late for meetings, your documents are delivered on time, you meet your minor milestone deadlines.
  • You take on responsibility for the project’s outcomes - so you are proactive about understanding what is being asked of you and you make sure you deliver exactly what it is you have been asked to deliver or better
  • You are consistent – you demonstrate your reliability by delivering the same excellent service over and over again.
[Late addition; See a new post on breaking reliability down to attributes here.]



6 April 2007

RATER: Service quality and projects

Both a business analyst and a project manager operate as consultants to a client organisation, and project teams operate as service delivery organisations. The RATER service quality framework is a good tool for project teams and team members to manage the quality of service to our clients.

I have written about RATER before and discussed where it came from and how it is supposed to work.

The five aspects of the RATER framework are reliability, assurance, tangibles, empathy and responsiveness, and it is performance on these measurable features that have been shown to most influence customer perceptions of quality.

Of course the relative importance of each aspect will vary from project to project and stakeholder to stakeholder. The PM and/or BA will have to use their instincts and analysis skills to work out what is most important to whom.

The PM and BA are the primary points of contact for the project team into the client organisation and they are where this system can make the best impact, but anyone on a project team could learn from this framework and apply it to how they deal with their clients and stakeholders.

This week I want to delver further into RATER in the project context. I want to discuss how project teams, and in particular project mangers and business analysts, can use RATER to improve their effectiveness and their stakeholder’s satisfaction with their work.

What makes me think that RATER is appropriate to projects is the belief that many projects have two faces to their success. One is the delivery of the scope – was it on time, to quality and at the right price? And the other is the personal experience the team deliver along the way.

For example, in many organisations the team is expected to deliver a bunch of additional things, like compliance to business processes, happy peripheral stakeholders, coaching and developing junior staff (next season’s BAs) and so on.

So, each of the next five posts will look at the five aspects of the RATER model and see how they could be applied by PM/BAs and project teams.

3 April 2007

Requirements Management; Walk the RM trail

Browsing the internet for ideas to post on this week I discovered this website about requirements management; Managing Requirements by Ludwic Consulting Services LLC.

It is an IT focused site that provides good definitions, case studies of requirements gone wrong and a neat “Walk the RM trail” guided tour of the Requirements Management process.

Later this month I will be posting some more information on requirements management and think this site will provide a good counterpoint to my more broadly focused “business requirements” approach.
Source: http://www.jiludwig.com/