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.

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.

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.

.
Image from
TheBrickTestament.

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.

The presentation is due to be made on the 7th March to the Irish .Net Developers association at Buswells Hotel in Dublin.

Take a look at the presentation (in progress), and leave comments here with your feedback!

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

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.

• Keep it simple
• Document well, then document some more
• Good project management is still vital.
• Connect with the team, early and often.

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?

Metrics

1. Use Cases Completed (e.g. Track using XPlanner)
2. Tests (Junit) written to confrim that these use cases are complete.
3. Percentage of Unit Tests Running (should be 100%)
4. Code Coverage of these tests (using NoUnit)
5. Code Quality (Sun Javadoc Quality Checker, Code Review)

Even in this market, I hear prospective employers say ‘it’s very difficult to find good people’. We found that ourselves when were we building the Red Piranha framework. While they did well at the initial interview any people we looked at claiming to know Enterprise Java turned out to lack the experience, or were missing key areas (like xml, database access or even how to build the project).

Our solution was to outsource the IT project. While we designed and built key areas, some of the more mundane coding we outsourced overseas. Given that we’re not the largest of companies, how did we use this? We used a website called Rent a Coder , but there are alternatives like Elance , Guru and Get a Freelancer .

What all these sites give you is

• A place to post IT Projects and work that you want done online.
• A way for prospective suppliers to make bids on your project.
• A way for you to rate suppliers by seeing their history, refereneces and work that they have done before.
• A way for you to select a supplier and put payment in Escrow (a secure ‘bank account’ that doesn’t get released until you’re satisfied that the work is done, so that the supplier is confident of getting paid).
• A way of resolving disputes.
• A way of monitoring progress and communicating with the supplier. The communications are recorded to help resolve disputes should they arise.
• A way of releasing payment to the supplier once the work is complete.

Haydn Shaughnessy writes in the Irish Times Business Section (Dec 15th 2005 ) about about the new possibilites.

All very well and good, but there are still risks , even for Small and Medium sized companies (SME’s) sending their project overseas. Most of these can be mitigated by good project management, but some ‘best practices’ to help manage your supplier include:

How to get it right

• Keep the projects small to medium size – there are few big projects that cannot be broken down into smaller chunks.
• Start with a ‘low business risk’ project. Not only will this help you learn how to outsource, but it can help you build up relationships with key suppliers that you can use again and again.
• Go by reputation – other people will have dealt with these suppliers before.
• You get what you pay for : some of the bids may be extremely cheap. Often these are legitimate companies looking to build a reputation. sometimes they may be just students looking for pocket money – fine if your business can take that risk.
• Play the game. It’s not just the suppliers that gets rated. Remember that you have a rating as well that will affect people making bids on your projects in the future.

And remember …

• Know what you want when you begin. Like any project, if you change your mind, it gives the people working for you an escape route to charge you more.
• Write it down in as much detail as possible. Often, you forget just hom much you know about your business – new people coming in won’t know this.
• You get what you can measure. Write what you want in a way that you can ask ‘was this feature delivered’ and get a yes/no answer.
• Don’t overload the project. It might be tempting to load on a lot of ‘nice to have features’, but could they wait until phase 2?
• Make yourself available to answer questions and quickly. Every specification will need some clarification, but it aslo  shows the supplier the importance that you attach to the project.

If you’re not sure what that means , give FirstPartners.net a call. We’re IT people, with a background in Supplier Management, Procurement and Purchasing. We’re available on +353 87 1224449, +44 2081 23 2081 , email PaulBrowne at Firstpartners.net.

Now if only Elance did plumbers …

Are you planning to outsource any or part of your next project?

(Part 1) suggests what is obvious (that there are different types of projects), but more usefully classifies them into two types. Type 1 are those that deliver concrete goods (like roads, bridges and office blocks). Type 2 are fuzzier projects aiming to change things, such as a process or organisational culture. It’s much harder to determine success in this second set, as they tend to deliver intangible results (i.e. you can’t drop them on your foot) . They also tend to suffer greater rates of failure. IT projects tend to be Type 2.

Some depressing statistics that if you’re lucky have only read about , or if you’re unlucky, know from personal experience. According to the Standish group, 31% of IT projects are cancelled outright, and over half have such serious performance issues that they were fortunate to escape the same fate. In contrast, a 3% overrun on a construction project is often the trigger for a public enquiry.

While there are many ‘excuses’ given for project failure, the author suggests that often the root cause is over-optimism and ‘biting off more than you can chew’. Symptoms of this over-optimism include projects started without any tolerances set, no change control and without proper reporting structures in place.

The 2nd Part of the article , is a bit more optimisitc, in that starts to tell you what you can do to improve the rates of project success. Broadly speaking , there are two areas suggested for this:

For more details , here are links to part 1 and part 2 of the article.
http://www.itarchitect.co.uk/articles/display.asp?id=203
http://www.itarchitect.co.uk/articles/display.asp?id=224

* The market for idea’s is one of the key drivers of Economic Growth.
* Large Companies are gathering Patents as a means of defense against other people enforcing patent claims on them.
* Patents , if used unwisely, can be a bit like the tolls that used to be charged travellers – good for the local warlords but bad for everybody else.
* Many large companies , including IBM and Novell are donating Patents to Open source as a means of helping the open software , and hence their own , interests.
* As other countries (e.g. China and India) gather their own Patent portfolio, the attitude to Patents and Copyright, instead of one way traffic, will become more balanced – for example the US Cogress was ready to forcibly licence an anti-anthrax drug from a German Company post 9-11. Expect

A good forum for expressing your views on Patents is Digitial Rights Ireland.

One of the chapters is titled ‘Estate Agents and the Klu Klux Klan’ , where the authors show the power of information – in the first instance how Estate Agents use their market knowledge to get higher prices for their own house (by a couple of thousand dollars on average). In the 2nd instance it shows how information was used to stop the Klan revival in it’s tracks (by giving out information on the funny handshakes in a childrens cartoon).

So what has all this to with IT consultancy? The moral of the story is that when hiring somebody with more knowledge than you (be it a plumber or a Sys admin) be very very careful. More than ever , get references from the candidates and follow them up. If you ask me nicely, I’ll tell you a ‘how not to do it story’ which can’t be published here for legal reasons ….

As an aside , to do with information and the power of the internet , take a look at the New Orleans Hurricane Katrina information map. People are using a combination of google maps and blogs to give a real picture of the situation on the ground. While the picture may be surprisingly ‘normal’ (after all the people posting still have internet connections), it shows that the internet is still producing cultural aftershocks 10 years after it’s introduction.

It’s hard to ignore people, even half a world away, when they’re posting information about how the floodwaters are rising by the minute.