Interesting Old Stuff: Management tutorial

I  browsed through an old mailbox I used long ago today, and stumbled upon an old weekly tutorial for a project management class I attended.  That week's tutorial seems like it was about methodologies, continuous feedback and client demonstration. I know I would have a lot to say about that now :)

 

An interesting read out of a sort of sentimental fashion for me. I'll post it here just for fun

 

You are the IT project manager of an organisation developing innovative ‘leading-edge’ warehousing solutions. Although a number of individual software components have yet to be completed your clients are insisting on regular updates of your progress, backed up by demonstrations of the latest versions of the individual software components. Their insistence is being reinforced by the client’s threat to withhold staged payments that are required to be made as part of the contract terms.

 

How might this type of client behaviour affect the type of development methodology you employ?

With any project we believe it is important to supply the client with regular updates and demonstrations of the latest versions of the individual software components. When dealing with a very insistent client, as in this case, we believe that there is a need to use a methodology that incorporates user/client involvement throughout the project.

The development methodology type that is most suited for these requirements is one based on prototyping. By using such a methodology the project will focus on and deliver working prototypes, and show early efforts of integrating the different parts of the project. An example of a methodology that could be suitable for this type of project is Extreme Programming (XP). XP is a spiral type methodology with short iterations and close customer contact. It has a strong focus on integrating early and creating working prototypes. Since the customer will be updated on the progress of the project at short intervals and are able to change direction due to problems or new requirements they will be able to do real-time planning with the project.

Generally we believe that it is important to know and understand any development methodology, and not use any aspect of it without considering the consequences. Often you need to use parts of different methodologies, or change part of the one you are using, as it does not necessarily work perfect in your organisation.

 

Why do you believe the client might be so insistent on receiving regular ‘proof of progress’ updates?

There are many possible reasons for why a client would insist on receiving regular “proof of progress” updates. We believe that such an insistent client’s main reason for behaving like that is the risk of project failure. It is well known that many IT projects fail to complete at all, complete far over time or budget, or just isn’t used as planned in the organisation.

During a project there are many problems that occur. A client wants to see that everything is going as planned, that the project milestones are met, and that the contracted agreements are fulfilled.

If a project develops away from the project specifications and the project plan agreed upon with the client, then the client can demand corrections according to the contract or even bail out. The earlier this is discovered, the better it is for the client.

You discuss the issue with your own executive management and they make a suggestion that you merely ‘fake’ the demonstrations without making any genuine attempt to provide a genuine product. What are some of the implications here?

If you were to “fake” the demonstration of a product we believe that there can be both positive and negative implications to this.

Firstly, it might be positive for the project to do this if you are having a slow start to the project but you are still very confident that you will be able to finish the section in question on time.

Another reason might be if you are up to date on the coding, but you might still have problems showing visual proof of progress. By faking the demonstration you can avoid problems you might get by not producing visual results. In other words you will not be picking the low hanging fruits first just to have something to demonstrate.

On the other hand there are some negative implications too. You can risk giving the client false hopes about the probability of project success. If the client detects the faking of the demonstration you will have to take the consequences. This can range from the client loosing trust in you, a loss of reputation and a loss of the contract to possible lawsuits.

All of these negative implications are risks that can lead to economical consequences. Therefore it’s important that you consider the implications thoroughly before making a decision to fake such a presentation.