By If you’ve ever been singed by a ‘bad’ implementation (of an expanded software project, a RMIS implementation, a home renovation), you tend to approach new projects with a sense of trepidation and dread. Today I will walk through the steps I take to try to avoid a project meltdown. I call it ‘how you can control your controllables'(a phrase I borrowed from Dave Ramsey’s talk show). You likely are doing many of these steps already, perhaps in a different order…or you’re bumping into them mid-way through your project and then reworking deliverables. Hope this helps.
Mary’s 8 Step Program
- Define the business need
- Define the ‘success’
- Define your reporting needs
- Define/Walk through expected workflows
- Identify responsible parties for each action
- Draft up screens
- Identify any security requirements
- Review with a neutral party
Define the business need – This seems like an obvious step, but you’d be surprised. Ask the question why. Multiple times. There has to be a need for the project – a problem that you are solving…And while I might accept ‘We have $ burning a hole in our pocket’, the next step would stop you. In these beginning stages, the salesperson is trying to figure out: 1) how much $ could you have (your budget) 2) how to translate what you’re saying to an actual deliverable (the scope).
As an example, I might say to a home contractor, “I’ve always hated this backsplash.” S/he would translate that to “Remove and Retile.”
For a RMIS, you might tell your service rep, “I don’t even know why we ask this question any more”. S/he would translate that to “Make field unrequired” or “Remove field from screens and delete.”
Define the ‘success’ – I used to start my kick-off calls with this questions, with mixed results. Some clients felt this was a ‘cheesy’ question, perhaps irrelevant because at that point the statement of work had already been signed. I still liked to ask it because the questions helps to confirm if the project is spec’ed out properly. It also is an opportunity for us to hear together (and validate together) what success is. I’m working with a client who talks about working backwards, which this is a play on. When all is said and done and the dust has settled, how do we know we are successful? This can be light and airy, but really works well with more definition (without being too granular). A few examples for a RMIS implementation. Which one do you like?
- Success is defined as website available to the public that allows them to enter an incident online. Upon submission, our team is notified and automatically assigned based on capacity. The system will help us to decrease the lag time from loss date to notification date and improve capacity management of our staff.
- Success is an online portal
- Success is implementation of an online portal and the decommissioning of outdated incident intake system, saving $25,000 in licensing cost.
Can you imagine how the project may head in a different direction based on these definitions of success?
Define your reporting needs – I rarely get a client to commit to this step. I don’t know if there’s a concern that I’m locking them to only a subset of reports or if they can’t visualize reports in their head. Still it is an important exercise to go through, as it may uncover some foundational needs.
Define/Walk through expected workflows – I just ran through this step with a client with great success. We discovered there was a need for an invoicing component. It’s much nicer to find that out now at the beginning then 1 week before go live in a training session (and yes that happened to me once with a client in Raleigh years ago).
Identify responsible parties for each action – Just like any action item list, you’ve got to ‘assign’ it to someone, otherwise it won’t get done. Be clear on your workflows (above) what actions are expected and by whom…and be clear in your requirements who you expect to complete a task. Otherwise, your vendor may think you’re building a bunch of email templates while you think the reverse.
Draft up screens – The goal with this step is to help visualize the end user experience…and if different users should have different experiences.
Identify any security requirements – okay, I’ll be honest. Every one blows this off until the last minute unless you have someone from IT in the room. This can be a simple excel table/matrix that is ‘access/no access’ but there’s usual more finesse around it (ability to delete – the answer is NO, ability to view only, ability to write notes, etc.). I tend to be more generous around security because I don’t want to micromanage access (thinking ahead to maintenance and success). That being said, there are certain sensitive items that should be restricted.
Review with a neutral party – I did this recently on a project spec and it was eye opening how helpful this last step is. The person helped me to see how many assumptions I had made that were not in the document, which could have greatly impacted the timeline. Your specification has to be written as if the person doing the work as little to no work experience and little to no knowledge of the industry. That’s just a truth you have to accept.
Now…it would be nice if this was handled by someone else, especially when your team is already overworked. I cannot stress enough how taking these steps will help you control your controllables. Will it prevent hiccups? Yes. Of course you may miss some, but taking the time and effort is definitely worth it.
Like many projects, the level of experience of your ‘crew’ and their capacity will impact the outcome. Some of that is out of your control. Choose your consultants wisely and have the discussion up front so you are aware of any risks (that’s called good risk management).