The Art of Planning

Whether you’re a sports team embarking on a new season, a surgeon preparing for a busy day of surgery, a system admin preparing to introduce a new system to your organization, or planning dinner for your family, having a plan is of critical importance.

Okay, great. A plan. I can make a plan. Let’s use the dinner example…

The Plan – An Example

The Plan in Theory: I’ll get home around 5 and get tacos ready. We’ll be eating by 5:30 and we can go for a lovely walk and enjoy a quiet evening.

The Plan in Reality: Took a last minute call and didn’t leave my desk until 5:15. Realized on my way to the car we didn’t take any ground beef out of the freezer so I’ve got to stop at the store. Get home and realize the youngest is having a homework meltdown – need to calm them down and get them on the right track.

Phew, okay, child is in good spirits again. It’s 5:45 now. That’s okay, tacos are quick.

Wait, the dishwasher didn’t run?! Shoot, the pan I need is in there. Okay, quick wash of that and we’re good to go. Oh, a text…one sec…okay, responded. Moving on.

Great, beef is on. Geez, how is it 6 already? Okay, tacos…*opens fridge*…sour cream, lettuce…eww, that’s wilty…cut around and find the good parts. Cheese. Wait, we don’t have any cheese?! Come’on…whatever, fine, cheese is basically just pure fat anyway, we are healthier without it. Salsa – well, that *should* be enough for all of us…

Wait, what’s that smell…THE BEEF!

Perhaps a bit of an exaggeration but I can tell you that story is based on mostly reality in our house. When we don’t have a plan, things can become infinitely more difficult.

Systems Planning

Dinner is one thing. Planning to select, configure, and roll out a system to support your organization is a whole other ball game, but the basic principle remains true – it’s easier with a plan.

Over the years I’ve seen various systems and tools rolled out to organizations. Those experiences have surfaced some effective practices that I think are beneficial to pass along. This post could be a series in and of itself. Maybe one day I’ll do just that, but here are what I think are pretty integral aspects.

Identify Needs and Prioritize

What business goals are you trying to solve? Truly think / talk this through with your organization. It’s not just “a system to track our people” – WHY are you tracking those people? What is it that you are doing with all that tracked information? What purpose does it serve? As you start to peel those layers away you will start to get at the core of what your organization truly “needs”. All of a sudden the “a system to track our people” becomes “communicate more effectively with our constituents” or “better understand the needs of our customers”.

Then, prioritize those. What are minimum viable product aspects (the ones that you cannot go live without) and which are ‘nice-to-haves (the ones that, if not in phase one, could be slide into a future phase of development).

Think Process

It’s easy to get lost in the world of fields and specifics. There are rabbit holes you could go down at every turn, but try to take as step back from this to examine the entire organizational process you’re working with. Instead of “we’ll use leads”, think about what “use leads” means – have you defined what a lead is in your organization? When does a lead get created? How does the lead get created? If manually, who creates the lead? What information is required for people to action those leads? There are many other questions and each answer provides deeper insight into the overarching business process you’re trying to augment with the system in question.

Perhaps your building an app to manage an internal process – the same principles apply. Example: submitting for a refund approval. Where does the request come from? How does that request get to the appropriate approvers? Who are the appropriate approvers? Who needs to action the request once it’s approved? What information does that department need to action the process?

Asking questions is key. While it may be annoying to some people, if we don’t know the answer and act on what we think, we’re making an assumption. And we all know what happens when we make assumptions!

Define Success

One of the best lines I read in a book (Brene Brown’s “Dare to Lead” – you should read it) is the concept of “Paint Done”. The idea stems from avoiding assumptions and being clear and intentional about what we are asking for or, if the receiver, in understanding what someone is asking for.

I fell in love with this idea as soon as I heard it and folded a piece of paper over the top of my computer screen so I see it while on every video call (the primary means of communication in my org). I started asking it casually when we were talking about a task or project just as Brene presented it in her book; “Okay team, let’s talk about the end game for a second – paint done for me”. The results were staggering! It frames the discussion around what success for the project or task is, and helps us surface key questions around how this item will be delivered when it’s ready. I don’t see a future where this isn’t part of my approach, it’s THAT impactful.

When thinking about what the end game of this systems rollout is, think about what “done” looks like. This will help you define KPI’s (key performance indicators) for your project stakeholders and executive team. It’s much easier to provide an update on progress or completion when you can say “We know we’re on our way because done looks like X and we can see that taking shape here, here and here” or “done looked like X, and X is what we have”.

Be Organized

Just as there are near infinite combinations of topics for tacos, I’ve seen requirements captured in various ways. Scratch pads, Word docs, spreadsheets, “To Do” software, and formal project management/issue tracking software.

I’m a fan of consistency in approach and process. However you elect to capture requirements it should be done in a predictable manner. I find the greatest success when I have a system that captures the pertinent information in a uniform way. What information? I typically strive to answer these questions:

  • What is the business trying to accomplish?
  • What is the gap we’ve identified that prevents the goal OR is making that goal more difficult to realize?
  • Who is impacted (stakeholders)?
  • How are they impacted?
  • What are your stakeholders expectations for how this/these gap(s) are mitigated?

These are your stakeholder requirements. They help you frame the business need you are trying to fulfill and how your stakeholders expect that gap to be dealt with. You need to be mindful that sometimes what your users *think* they want is not what they truly need. It is your job to call that out as the process unfolds and support them through this.

With this, the systems team can start to work toward identifying two-three options for how this problem can be solved.

From there we can typically start to anchor discussion with the stakeholders around how we want to tackle the item. Having the information in a consistent format with the same questions being asked each time helps us frame the issue in a comprehensive way.

Take Control, but Don’t be Controlling

Your users need to be the voices fueling the needs for the system, but they need the process to be managed. You are the one steering the ship and you need to be a good captain. What does that mean? It means you are identifying the right people to be engaged in the discussion at the right times. You are engaging external resources for insight and guidance as appropriate, and you are keeping the team informed along the way. It’s your job to build out the path to achieving ‘done’ based on all the input and feedback from the team. They are looking for your leadership here.

We all know that saying…’with great power comes great responsibility’ (thanks, Voltaire – or, Peter Parker’s Uncle Ben, if you prefer). It can be difficult to tease out the common threads of various teams having input on the same system. Asking questions, particularly “why”, is your friend . Just as how children who are given firm but reasonable boundaries tend to respect those boundaries and why they exist in the long run, your users will respect your thorough, inquisitive approach to understanding what they truly require from the system.

Wrapping Up…

I maintain that having a plan is the key to success for most things in life. I find the points above help guide my approach to systems projects, and help me to keep the team engaged, the process organized, and the focal point on what the ultimate goals of the project are.

I’d love to hear what you think of these points and what you find useful in your world! Drop a comment below!

We’re all learning. Why not learn together?

Cover Image: Photo by Glenn Carstens-Peters on Unsplash

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s