Setting the right expectation: Project mgmt & Business Analysis short essays

While the 'Sales teams' can forget later, and use juicy words while making pitches, clients often don't forget promises and lofty pitches so easily. Especially in the IT landscape, where the sales team closes a deal, the delivery team often is left high and dry with the expectations which are set with the client. More or less, the responsibility lies with the project manager or the account manager to set the right expectations, which pave way for mutual success.
Here are some of the points, around which managing and setting expectations is crucial, and attention needs to be paid.
Knowing Self & pitching to strengths:
This has been time tested and most of the projects fail on this account. The teams, in fear of losing client confidence/revenue/account, accept work which client pushes over, or wants to get done. This usually follows with a difficult situation, when not really being able to deliver puts you into much difficult situation. Hence, its key to know the self, your own composition. if the company has great back-end technical resources, but lacks in front end UI resources, they need to know and accept the reality. If a company doesn't have vendor management skills, it will terrible to accept program management engagements.
The 'Said' and the 'Un-said':
Its extremely important to listen to the client thoroughly and understand the ask clearly. Sometimes, we prejudge the needs. sometimes, we assume certain things, without feeling the need to clarify the assumptions. Lot of those assumptions fall flat on key moments leading into embarrassment. hence, for delivery teams and project managers, its very important to understand and detail what has been 'said' or 'asked' by the client. Also, it is equally important to decipher the 'un-said' by analyzing their business market, needs, and their 'ask'. Most of the times, the client would be appreciative if you go back to them and clarify things, which you are assuming. You may get a lot of perspective hearing from them, and may be able to plan better.
Don't commit to please, commit to deliver:
You might have seen 'yes man'. Lot of the IT projects start and run like that, until the mayday signs appear and time runs out. Don't commit on that additional piece of code, just to please an executive. Don't overcommit if the vitals statistics of the project don't allow it. It is of no use to take additional work now, and jeopardising the complete delivery later. Clients, while may be unhappy on not being able to get that 'important' feature out, but would appreciate if you can show them the larger picture and plan to accommodate their request for later.
Moving quickly and timely actions:
A lot of time, either the project teams are not confident, or lack clarity to get back to the client. If you have to break a bad news, do it fast. if there is something which has been committed to, but you are not confident of delivering it, raise the 'red flag' now. Lot of times, lack of timely action worsens the situations. Often, it is understood, that if you don't raise it up, then things are in control, hence quick actions can save a lot of trouble at later point in time.
Comments
Post a Comment