I’ve had a number of project and operational issues to deal with over the last couple of weeks. Strangely enough, they’ve all had the same root problem.
See if any of these sound familiar:
“We thought you were going to pay for design…”
“We didn’t realise we had to allocate people to do the user acceptance testing. Can’t you do that for us?”
“I know it’s not in the spec, but we really need it.”
“Data quality? Isn’t that an IT issue?”
“You said it was only five days work. That means I should have it by next week!”
I’m sure you’ve all got it now; lack of clarity regarding roles and responsibilities. If responsibilities are not properly understood at the outset, then it’s extremely likely that there will be major headaches later on. Furthermore, it’s an issue that affects all aspects of IT, operational issues, projects, budgets etc, and has a huge impact on how people see us.
However good a job you’re doing, lack of clarity will always lead to disappointment and unmet expectations, and that’s why it’s important to be crystal clear about the scope of work. Of course, from an operational perspective, a Service Catalogue is definitely the way forward (as long as this is realistic and communicated to IT users) but for projects it can be bit trickier.
This problem is exacerbated by the fact that many people don’t really understand how IT Departments work, so they naturally assume we can do anything and everything. And when we do pull out all the stops to do an amazing piece of work, that becomes the norm, rather than an exception. Of course, most of us in IT really want to help the users, and sometimes we can give an over optimistic view of timescales or scope, because we know that’s what the user really wants to hear.
There’s also the distinction between the amount of effort something will require, and elapsed time, which aren’t usually the same thing. It’s very important to be clear when delivery will be, not how long it will actually take to do.
I try to follow the example of the commercial sector by considering every commitment I make to have financial implications. Private companies, for obvious reasons, are much better at scoping work than internal teams because commercially, it’s important for them to get this right. Having said that, I have seen a number of contract disputes which have arisen because of confusion relating to the scope of services which were to be provided.
These points all highlight why clarity of responsibility is so important in order to avoid these sorts of issues, be crystal clear about the deliverables are, when the user can expect to receive them, and what the users’ responsibilities are to actually gain the benefit. If a clear expectation is set early on, it will pay dividends.