New and established customers, whether internal or external, may be laboring under various misconceptions about what he or she can expect from the development process and from you as the project manager. Those misconceptions may result in miscommunication if you aren't careful.
You can begin dispelling these myths about IT project management after recognising that they may be lurking in the mind of your next customer.
Client myth #1: If no visible coding occurs in the first week of a project, perhaps I should complain about the PM, demand that more people work on the project, take over running the project myself, or pull the plug. Sometimes it's difficult to stand up to demands for visible action when thinking and planning are actually more valuable.
Client myth #2: If I don't get a project report every two days, then the project manager must be slacking. Nervous clients are usually the ones who foster this myth because some clients are inclined to believe that your job is all about reporting to him or her. An easy way to combat this myth is to state the reporting frequency and milestones at the outset. It is also always a good idea to describe what this will actually mean in practice.
Client myth #3: If the graph they show me indicates less work has been completed than was estimated by this stage, it's time to... (See myth #1). Don't expect clients to already know that the IT project path isn't always one of steady progress. Setbacks and shortcuts will occur. It's easier to explain this reality before work begins than when you're in the middle of dealing with some small-scale development crisis.
Client myth #4: When I see the code running for the first time, the whole project is obviously only days from completion. Oh dear. In your eagerness to show off your team's productivity, it's vital that you don't give the impression that the work is markedly ahead of scheduleââ,¬"regardless of whether it is or isn't.
Client myth #5: Although the project manager usually complains, I can demand changes to the specification at any stage. It's the PM's job to be flexible. It's true that flexibility is an essential project management skill. However, a clear explanation of the cost implications of last-minute design changes will usually cool a client's ardor for radical alterations to the spec.
Client myth #6: My technical manager asked the project manager a question, and the PM had to have a colleague answer for him. Customers often misunderstand that the role of the project manager isn't to be the technical guru on every aspect of the work. Don't be afraid to seek expertise from your team and show that you rely on them.
Client myth #7: I once wrote some programs as part of my degree in business studies. How much harder can the current project be? You somehow have to communicate the fact that complexity doesn't scale. In addition, the value of a professional buildââ,¬"in terms of reliability, code life, robustness, understandability, and so onââ,¬"needs to be made crystal clear.
Client myth #8: The customer is always right. Actually, this one isn't a myth. The customer is always rightââ,¬"as long as they are prepared to pay for the service.
Although some customers will bring biases and preconceptions to a project, a PM must help them understand that acting as if these myths were true can only damage the chances of successful delivery.
2%
4%
