Everyone wants to play with the latest and greatest toy, right? And when it comes to bring to reality that solution your client wants on their creative project, the urge is to implement the most cutting edge technology as possible. Come on…we’ve all felt it. Chances are, we’ve all had more than one client come to us begging us to use the technology they’ve suggested because they “heard” somewhere that this latest tech innovation would do everything they needed and more. All problems would be solved. Or maybe they just thought it would be cool and they had a big enough budget to cover it.
So, the big question after all this temptation is this… Should we ever really let technology drive the end solution? The smart answer – the only real right answer is “No.” (Not even the best project management software for creative agencies should drive that decision!)
And deep down we all know that. Even those excitable clients should know that, no matter how blind they may seem to that fact. Technology should not drive the solution. It’s just bad business practice and it’s bad project management practice. It may end up being the solution, but you need to get to that decision through proper planning and requirements analysis first…we all know that. We can’t be the “yes man” for the client when they come begging for a particular solution on a creative project – we may end up implementing something they don’t really need, something far more costly than what solves their project problem, and something that doesn’t really work for them. In the long run that will never = happy client.
In order to best ensure that you’re going to be providing the client with the actual solution that their need requires, you’ll need to follow a process similar to the following when working on the project request:
Get the client to map out their current processes
Mapping out their own business processes is something that is very helpful for the client to do, but they’ll often overlook this activity unless you specifically require it. It’s really a good idea to require that they go through this activity before you ever even sit down with them. If the client goes to their end users and subject matter experts (SMEs), and gets business processes mapped out with them, then there’s a real good chance that they’ll have the best possible view of their real need going into requirements definition on their own or with you.
Go through high-level requirements with the client
Ideally, the client would do this on their own. But what’s ideal and what the client actually does isn’t the same thing. So, assuming that you and your team have to at least ‘help’ the client map out their high level requirements, at least you’ll have their business processes in place from the previous step to really help you understand what their need is.
Document detailed requirements
Next, drill down with the client further into the requirements. It’s best at this time to also categorize and prioritize requirements. The key is to capture more requirements detail at this point to add to what you already have captured at a high level through the client discussions in the previous step.
It’s inevitable that there will be three general categories of requirements: must-haves (the #1s), should-haves (the #2s), and nice-to-haves (the #3s). Prioritizing now will help you later if and when scope or schedule changes affect the project and you have to get functionality up and running by a specific date leaving the rest for a later phase of the implementation. Then, you’ll be able to focus on first getting all the #1 requirements met, if necessary, and push #2’s and #3’s to a later phase rather than watch the entire project crash or go over budget and time.
Propose a solution
Unless it’s already obvious, now is the more likely time to actually propose the technology for the solution. Up to this point we’ve been examining the current processes and need and detailing the requirements. Now, based on all of that information we can propose or confirm the right solution to meet the client’s needs for their creative project. Now is when the real work of utilizing the proposed solution to meet the requirements of the project can start to happen.
Technology is cool – I’ll give you that. And we all want to work with the latest technology as much as possible. It excites us. The project sponsor on the other side of the equation is often no different. They may consider it some kind of feather in their cap to implement a project with some new cool technology. They may have even been directed to do this by someone higher up in their organization. Resist that temptation. Push back, go through the proper planning process and then – and only then – can you really know what your client needs and what technology will solve their problem or fulfill their needs.