This concept works no matter which side of the fence you’re on – it’s just good sound advice. I was once being courted for a tech management position for an Iowa-based company that had to be stuck in one of the most boring non-tech industries in America…so the actual IT department was rather small.
The inside concern
The CIO was concerned that he was always being stonewalled by the lead tech guys on estimates and needed someone in the middle to run the show and keep the lead techs in check. I’ve always been good at estimating development work and I use that to my advantage as a project manager and consultant when pricing change orders and consulting engagements. I always estimate work that I’ve asked technical project team members to estimate as well. Then, when they turn in their estimates, I compare mine with theirs and I go back to them to discuss any big discrepancies. There may be something I missed, or an assumption that I wasn’t aware of…but it’s a good check to make sure you’re presenting your project customer with the best estimate possible – for the sake of project success and customer satisfaction.
My CIO scenario highlights the problems that just not being aware can cause one individual, a position of responsibility, a business unit and ultimately an entire organization. This guy needed to hire an entire position and restructure the IT group just because he was concerned that he couldn’t keep the staff from padding estimates and frustrating him on development initiatives. And he was the CIO. You can probably understand why I quickly realized it was not a wise move for me to make.
Customers must also be aware
And that goes for the customer side, too. You could argue that in the above scenario the hiring manager with the trust issues was actually is internal customer. But consider a true external customer. They care about how long a project is going to take and may have hard deadlines to meet as a result because of promises they’ve made in their organization, to end users and to 3rd party vendors. On their side of the coin the deadline for rollout may be far more important than the budget – though we all know those two are very closely related anyway.
So customers, be careful when giving deadlines to your solution providers. If you say you need something done by February 1st, keep in mind what that means to you on your side. Why? Because, as a project manager and consultant, if you give me that date that will be my rollout date that I’ll work back from on the project. In reality, you probably need delivery earlier than that as you have commitments and signoffs and training and other deployment related issues on your side to consider. You need to know enough about the project, the need and the solution to know about how long it should take before entering into an engagement. If you don’t, your solution provider will likely make the work fill the available time – which could take out all risk padding time and may end up costing your group extra money on the project paying for a full project staff for the entire time frame.
Don’t be the CIO of the Iowa-based tool company. Don’t be clueless. Be informed and take control so you don’t get taken to the cleaners. Know how long it should take…then negotiate.
