Oh No. Support Department Wants Documentation. Again!

 

This week in the Project Shrink question box:

"Dear Project Shrink: The people from our technical support department always seek unreasonable arguments not to take the system into production. Now they need tons of documents, later they need to see more test results. What should I do?"

Transition from project to production is always an exciting time. If the project was a long and painful ride, it is the time for relieve for the project team members. The end of their misery. Slam dunk over the wall with the system, and their problems. In this case, it's no surprise the support department doesn't want your misery. So, they just keep piling up the arguments not having it as their responsibility.

Or, you actually agreed to deliver documentation and test results, and you didn't. When time is scarce the person in a business suit with the wallet has priority, not the maintenance guy in greasy jeans. So, it might be that the requirements from the support department got lower on the priority list. Too low.

I would recommend doing two things to avoid this situation: get a support guy on the project team. Make sure that some one that will be maintaining the system during production is part of the project from start to finish. This will ensure that you have no surprises at the end. You possibly still have to deliver those items, but you get your signals earlier.

Second, from project start, formulate all the requirements from the technical support department into "business requirements", like availability; arguments all stakeholders can relate to. This makes discussions about priorities during the project a lot easier.

For example a requirement like: "Every database should be Oracle." (or just pick a vendor you like). When buying a system, it can be simple. "Does it run Oracle? No? Sorry, we don't want it." But, normally you buy functionality and not technology. Especially a business person doesn't care. You buy a system for what it can do, and not because the bits and bytes are flipped in a certain way.

The stake here has to do with sharing database administrators among several systems. The company benefits from efficient use of employees. Especially concerning specialized people. Database administrators (DBAs) are a good example. Having more similar systems that these people can maintain, will make the costs of maintenance drop. Using a more mainstream database like Oracle, makes it also easier to get some outside people from the market to do the tasks when your own employees are overloaded or not available.

Now every person understands this.

So, one person on the team, and sharing the rationale and importance behind technical requirements with all stakeholders should help you out.

What's your suggestion?