Good practices in getting your development project done

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.

Advertisements

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

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?

NoUnit Development Process

Some notes on agile process based around NoUnit – to be expanded later

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)

How to Outsource – Why don't Elance do Plumbers?

Although not doing as spectacularly well as the construction industry, the IT jobs market in Dublin is ticking along very nicely. Not too nicely that we don’t have occasional thoughts about picking up a trade and going to work on a building site, but certainly a happy mid way point between the dot com boom and the dot com bust.

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?

Why IT Projects fail – mastering the monster

The UK based IT Architect site is running a series of articles on why IT Projects fail.

IT Architect Logo

(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:

    • Make Type 2 (IT) Projects more like Type 1 (Construction) – remove the fuzziness of success , so that you see the outputs of your project. This often comes down to metrics on the basis of ‘you get what you measure).
      Understand the level of success that you are aiming for. This can range from a simple level 1 (did the project do what was asked of it) , to Level 4 ( did the project have a positive impact on our business strategy). In between are Level 2 (Was this project success a once-off, or do *all* our projects suceed) and Level 3 (our projects may be successful, but are we working on the right ones).
  • 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

    Do Software Patents really Affect you?

    The Economist is running one of it’s in depth Surveys on Software Patents and the Market for idea’s. Some of the content is available online but here is the 10 second version:

    * 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.