Very early on in my career, I learned two very valuable lessons:
- Never confuse sales with implementation; and
- Be careful what you ask for
Whether I’ve been consulting, managing projects or in operational management roles both have had an influence in every project. They’re two lessons I speak about regularly with my mentees and encourage them to keep in mind as they develop their careers. Why? Because these two lessons can and do shape project outcomes.
I’ve listed two lessons but in this post I’m going to focus on the 2nd one, which isn’t as silly as it sounds and you’ll see why later.
When we think about projects the first thing that comes to mind, after the obvious budget and contract related elements, is defining the requirements. That is, being clear on the scope of the project. What does the project have to deliver in terms of functionality, controls, reporting, audit trails, transactions (batch or interactive), cost savings, productivity improvement, overhead and possible resource reductions etc? Whether it’s the immediate team or an indirect stakeholder, everyone has a genuine reason why certain functionality or functions are business critical. It’s during this time that the project manager must employ the following skills:
- The PM must allow ideas and initiative to flow while also staying focused on the task at hand and ultimate goal; and
- Be able to sift through all the requirements so as to nail down the real business needs and prioritize the wants.
These skills require facilitation, collaboration and bucket loads of diplomacy. As responsible PM’s who do more than tick boxes and file status reports, we must find just the right balance between being fair yet firm. It’s important to have some idea of the standard functionality vs what might require a configuration tweak or what could result in a modification. A small tweak that uses a seemingly unused field to satisfy a ‘nice to have’ could result in data being transacted that causes order fulfillment failures.
It is clear that what was asked for was delivered but now it’s delivered it’s actually not what was wanted. Lesson number 1—Be careful what you ask for.
And, when someone says to you ‘but I saw it in the demo!’ or ‘I was told it worked that way!’ check it out by running some tests in the test environment (because there is a test environment, right?) and find out how it impacts other functions. Don’t rely on the marketing materials and sales presentations. Hence Lesson number 2—Never confuse sales with implementation. What you see and hear in the demo isn’t always implementable.
So next time someone says to you ‘this is business critical, we can’t operate without it’, make sure they know what that means for the future and that they best be careful and absolutely certain that’s what they want.
