Project

Fixed Price? Don’t get Stung

Posted on by paulbrowne

Chances are , you get get paid on a ‘Time and Materials’ basis – either as an employee or a consultant. Chances are, you’ve also thought that some extra work , perhaps at a fixed price, would be a nice sideline. Before you dive in, remember the following 5 key points.

  1. Write a Project Outline. Say exactly what will (and just as importantly) won’t be carried out as part of the project. This can take a lot of time to put together, but is essential to avoid trouble later. Even better get the client to pay you to write this, as it’s vital for them as well.
  2. Client dependencies. Do you depend on the client to get things done? If so, specify exactly what the must provide and when. Can’t specify exactly when you need (and there are many projects where this is the case)? Then do the work on a time and Materials basis only.
  3. Be visible to end client. The temptation is to go into a dark corner and start coding. The trouble is that you emerge blinking into the daylight at the end to find (i) The client frantic with worry about how the project is going and (ii) that events have happened that you sh. ould have known about. Price in regular time on the client site to keep in touch.
  4. Contingency. A wise man once said (In this case the instructor at the PMBOK course in Chicago): ‘If you can’t carry out the project with 15% time left over , don’t start it. For fixed price projects, make this something like 30% as the client will ask you to do little ‘extras’ and you can’t ask for extra money for every single one.
  5. Almost as important as knowning when to start (see point 1) is knowing when to finish. Document everything and do a final ‘handover’ day (a good idea is to hand over a CD whith all project deliverables on it). If you don’t do this, the project will never end, and you will never get paid.

Notice that all these items are about process , and not technology. Put simply; you can mess up your project just as easily using Java , PHP or .Net . Mess up as an employee or consultant, you get shouted at by the boss. Mess up on a fixed price and you’re into serious pain as you burn through (unpaid) extra time.

Agile Project Management

Posted on by paulbrowne

It’s pretty ironic , given that I’ve already stood up and did a presentation on the topic to the INDA, but today we have a UCD exam in Agile Project Management.

In perhaps the worlds first use of a blog as an exam revision technique, here are the main features of Agile projects:

  • Working Software over Comprehensive documentation
  • Customer interaction over Contract negociation
  • Responding to change over following a plan
  • Individuals and interactions over processes and tools.

In the meantime , if you don’t have an exam this morning , check out the NoUnit Agile tool that we build and maintain.

NoUnit logo

How to talk to your Boss about Agile

Posted on by paulbrowne

We’re giving a talk about ‘how to talk to your boss about agile‘ for the Irish .Net Developers Association next Tuesday in Buswells hotel Dublin.

More details (including the slides themselves, as a preview of what you are missing) are available here in powerpoint, openoffice, pdf and flash formats. The slides explain how 4 pictures of bridges can explain the difference between Ad-Hoc , Predictive, Agile and XP projects. No , really , you do want to check this out.

Links to a lot of the sites / articles / tools used in the presentation are here on Del.icio.us. More posts on this blog about using agile techniques on projects are here.

The Bridges are:

  • Old Drogheda Bridge from the 1200’s – Quick and Dirty or Ad-Hoc project. Got the job done , and fast . Was patched a load of times, but eventually fell down under the weight of the traffic.
  • New Drogheda Motorway Bridge – Predictive Projects. Very easy to specify what you want (I want a bridge going from A-B to carry a motorway) and very easy to know when you are finished.
  • Drogheda Railway Brigde – Agile. Once the longest Iron Girder bridge in the world.Built in the 1850’s and the spec has kept on changing since. This included a complete rebuild in 1925 without losing a single days traffic. How’s that for unit testing?
  • Bungee Jumping off bridge in Queenstown – Extreme Programming (XP). Great fun if you’re doing it (and can be pretty effective), but scary for anybody watching.

As a sample of some of the pictures (which include lego people showing everything that can go wrong on a team), check out the image below.

source the brick testament.com.
Image from
TheBrickTestament.

How to avoid losing 150m Euro

Posted on by paulbrowne

It now seems obvious that the Healthcare Payroll system was destined to fail. If you were working on the project, I’m sure it felt very differently at the time. How can your projects avoid a similar fate? While IT may sometimes seem disconnected from reality, the following guidelines show that ‘Real World’ lessons still apply.

  1. Know what you want and stick to it. If you’re building a house and change the plans several times the builder is going to fleece you, no matter how low the initial quote was. The same goes for IT Projects – if you change your mind after the price is agreed, you’re going to pay more.
  2. If you don’t know what you’re doing , find a friend who does. I know very little about houses, so when I was buying my own I got a friendly surveyor to check it out. With IT projects, this ‘friend’ should be genuinely on your side, and have something to lose (e.g. financial or reputation) if things go wrong.
  3. Little and often is better. Like exercise, smaller projects that deliver results little but early are best. If the results are good, try a second (and third) round to add more functionality based on the feedback from users.
  4. It’s been all done before. Tailored suits cost a lot more than ready-made ones – and most people are happy with a ‘Good enough’ instead of ‘Perfect fit’. There are literally thousands of ‘off-the-peg’ computer systems out there ready for final alteration to what you need.
  5. If you don’t understand the answer, ask more questions. Thankfully the days we sat and nodded at the Doctor’s Latin words are long gone. IT Consultants may sometimes speak a different language, but if they can’t explain what they’re talking about in English that you understand, the chances are they’re trying to hide something.
  6. Don’t build on sand. Like houses , projects need good foundations. For IT Projects , the good foundations are sound knowledge of the Business Processes being coded into the system. Changing processes and changing IT systems at the same time is like building on sand.
  7. Sometimes the tortoise wins the race. Unless your entire business model is built around being the very first to market, then being a tortoise and letting others race ahead has very big advantages. Not only can you learn from other people’s mistakes, but the chances are you’ll get it at a much reduced cost – For example websites now cost a fraction of what they did during the dot.com boom.
  8. Use a safety net. When building houses, often the first thing to go up is scaffolding, for safety reasons. The equivalent safety net in IT is called ‘Unit Tests’. Not only do they help you get there faster, but they let you know if you’ve broken something you’ve already built.
  9. Be a good poker player. Good poker players never give away valuable cards. For IT projects, owning all cards mean just that – make sure that you have full rights to the solution so that you can still move tables and use a different supplier. Even if you never make the move, knowing that you can is an effective bargaining chip.

And finally …

When you are in a hole, stop digging. The decision to call a halt to the projects was no doubt a difficult one, and is to be applauded. Too often, the temptation is to keep on going and hope things will turn out right. Recognising problems at an early stage means there is more chance of being able to fix them.

Checklist for IT Contracts

Posted on by paulbrowne

The Irish Computer Society (ICS) has a useful checklist for Irish companies of things to watch out for when setting up an IT contracts.

These items include:

  1. Take a look at your ‘standard’ contract in the light of recent developments in IT
  2. Review how you can make your supplier selection process even better.
  3. Use competitive procurement if possible
  4. Keep electronic copies of contracts
  5. Have formal contracts in place
  6. Watch out for IPR and use source code escrow if necessary

Good practices in getting your development project done

Posted on by paulbrowne

A list of good observations on what works with development projects is over at FairlyGoodPractices.com.

No matter what your type of organisation, or the tools that you use (be it Java, .Net or Visual Basic), the key to project sucess is communication, communication, communication.

One of the more unorthodox suggestions are allowing people to change their environment (e.g. move out of their office cubes). It will raise a few eyebrows, but if it works, just do it.

The wisdom of crowds says your project will be a success..

Posted on by paulbrowne

The Google Blog has a nice page outlining how they use Crowd Wisdom to predict when , and how their internal projects will turn out.

The basic idea is that project participants and observers are given electronic ‘shares’ in the project. People are then free to buy and sell these shares based on what they think is likely to happen (the new office opens on time, a new project fails to deliver).

While it’s a game, it’s been proven to be more accurate than traditional areas of forecasting, probably because it gets input from so many people.

Could this tool predict your project success?