February 3, 2011

The Project Team - Project Series

I know that I have moved away from this series for a little while, but there are certainly still a few areas that I want to examine, comment on, whatever it is I'm doing here.

The next one is the structure of the Project Team, and more particularly, the business representative(s) on the project team.

Unfortunately projects involving IT can take a while to get in place, and organisations are not usually staffed to be able to lose valuable operational staff to a project for a long period of time. This brings another tension into projects that have IT components, since the business is reticent to lose skilled staff for long periods, so they will pressure the project team to deliver earlier, or make their staff member(s) available 'as required', or in the absolute worst case give the project team a staff member they are willing to part with for a long period.

Rule #1 for the business unit should be when choosing the business expert to give to the project team it should be a person that you really can't do without. Or put another way, if you are happy to let a person go to the project they are the wrong person for the project.

This is not rocket science. The role of the business expert in the project team is to inform the project and development staff about the business processes, and make decision about the product that the business will have to live with. So think about it, surely you don't want to give them a staff member who is less than effective in their role? You want to give them the person who understands everything, you want to give them the person that everyone else relies upon for support and assistance, you want to give them the person who you trust to train new staff in the business processes. It stands to reason that this would be the case.

However, as mentioned earlier you can't afford to lose this person for a long period of time, so what does the business do? This is where a lot of projects fall down. We had a project in Defence that was developing a system to support a particular business process. A position was chosen as the liaison point, which was not the best position but the business couldn't spare the people who actually did the job. The person in that position had their own thoughts about how things 'should' work in the space, and had the system designed to support their view of the world. Needless to say that there was a significant redesign task when other people finally saw the system.

The thing that I have learned is that you cannot rely on one person to inform the project of how the business works, and most projects seem to understand this. There should be a business person on the project team, someone to keep the IT people on the straight and narrow when they get too focused on the technical aspects and lose sight of what the system is being designed for (it happens). The business person is also an important role to assist with the communications and training development. But it is even more important to ensure that the project team has a stakeholder group with your best staff, and that they are engaged appropriately in the process of developing the system.

There should be a Goldilocks approach to this consultation - not too little, not too much, just enough.  The stakeholder group should not be asked to validate everything the project business member says, but they should be asked to validate processes early on, they should be shown the developing system at key times in the process and of course they need to be part of the test and trial process before full UAT is commenced.

A note for Project Managers and BAs - when you are developing the business case and doing process mapping ask the question 'who do you go to for help?' and ensure that the 1 or 2 people that the majority of staff mention are requested to be part of the project. Put the business on the spot to say that they won't give these people up and identify the risks involved. In my experience the business seldom thinks of the actual impact of giving you less than optimal staff.