Beyond the alphabet soup of PRINCE2, MSP, PMBOK, ITIL, Agile
We hear about perception being reality in service management space. When you are dealing with projects, expectation become the be all and and end all. How your project is perceived is proportional to the level of expectation about the outcomes that you have built.
In the project paradigm, cost is the easiest attribute to communicate. If the expectation in the business is that a particular deliverable will cost 100 hours and your team delivers it in 105, it will receive somewhat begrudging acceptance. 110 will get people thinking whether it was worth the effort. Conversely, if you had built the expectation that the cost would be 120 hours, then even if you spen 115, the business will consider it a great delivery.
This may sound non-sensical, but it is the truth. How does one go about building this expectation? Do you just inflate estimates to achieve this? You cannot necessarily do that. If you are a monopoly supplier like inhouse team, then you may be able to get away with consistently over estimating the effort. In a services business, there is competition for this work and you do not want to turn away business by being too conservative.
At the same time, you do not want to be forever undercutting your competition to get work. In that scenario, you are always left with the scraps to fight over. You are in it to make a profit. If my cost is going to be more than my fees, then it makes no sense to take the work on. This can be a difficult juggling act unless your sales and services teams work closely.
Expectation is not only some thing that you as a Project Manager end up managing from the customer side. What is a good project from a deliverables point of view, may not be a great financial success. If you are running a project on a time and materials basis and are accomplishing things much quicker than anticipated, you are in fact depriving yourself of income. How do you avoid that? I recommend undertaking additional testing and documentation to ensure higher quality.
If the same project is being delivered on a fixed fee basis then the drivers are different. Your motivation now is to ensure the minimum effort you can spend to have the outputs delivered. You can make good profit by being efficient. Yet, some customers will begrudge that. Your work may have saved the client 100 hours of pain and priced accordingly. But if you achieve that in 80, the client is upset with you being accused of taking them for a ride. Yet, the same customer conveniently forgets that you carried the risk on this and had the project taken 120 hours, you would have been forking out services for no fee. We want to have our cake, and eat it too.
Then here are always those projects, where the customers have a want that is far out of proportion of their cost appetite. Be wary of this. It is a very common occurrence. It may sound like a good idea at the inception of the project to sharpen your estimates to land the work. This can only lead to bad work. You are setting the project team up to having to cut corners. If you really have to discount, do so on the basis of rates. The work is what it is. There is no up-side to compromise on quality.
What makes things difficult is that there is no right or wrong answer. It totally depends on the environment.
Image Credit: pretensesoup.wordpress.com
Senior Project Manager at Eagle Technology, APMG Accredited ITIL, MSP + PRINCE2 Practitioner, governance expert, cricket fanatic, squash pretender. Opinions expressed are purely from my experience of leading teams and running projects, and in no way claims to represent those of my employers or customers.
Reblogged this on Sutoprise Avenue, A SutoCom Source.