,

Monkey biznuzz time mgmt startegy

🐵

If you’ve read my bio/current job/recent posts, you’ll know I do It consulting for a company in Quebec, Canada. 90% of my projects are 2 to 3 weeks long in scope, if we run out of time, two things will happen:

-The project will be paused
-The client will need to buy more hours

Neither of which is great

I’ve been in my current role for 2.5 years, more than half of my projects finish on-time, this is typical for everyone in our team, why? 🐵🐒 business

Defining Monkey business / examples

‘THINGS YOU DIDN’T ACCOUNT FOR / PLAN FOR THAT MESS UP YOUR SCHEDULE”

Here are some recent examples from my work over the past few years:

The above is just a sample from what I’ve seen. Bottom line, 🐵monkey business🐵will happen, it’s just a matter of when and how much time you’ll lose trying to stop said monkey’s from jumping on the bed

Mitigating monkey business

For the first year of my job, I mostly followed a ‘ronin / cowboy’ method of delivering projects, I did what I thought was best and called my co-workers for help when stuff went wrong. My work was more chaotic and stressful as a result

I like Chuck Berry, but this song was playing in my head far too often

I would estimate a lot of my projects ended up looking like this from a pie-chart perspective:

Coming into year 2, me and the other dudes on my team started to do weekly ‘best practices meetings each Friday afternoon. We didn’t just talk, we wrote stuff down into our WIKI, and made it LAW! As such, I started to follow a more pedantic method

  1. Following the OSI layer of troubleshooting, this has been drilled into since taking a Cisco CCNA course in 2004. I never did sit the exam to get the accreditation, but the troubleshooting steps remained with me. Here’s my related blog post on the topic

    TLDR; start with the basics when troubleshooting an issue, start at the physical layer and work your way up, troubleshooting layer 7 ‘app issues’ is not where you want to ever be, or to start
  2. Follow an SOP for your project deployment. In my job, we use Perfect WIKI, which is a teams add-in. Within your document(s), define how you deploy images, GPOS, install apps, etc
  3. A tie-in to the above, automate your standard operating procedures (SOP) as much as possible. Hand-installing an OS/apps/windows updates isn’t the way to go anymore, it’s error prone and slow
  4. Review the client’s environment during initial meetings, ID any potential sources for monkey biz, and if possible, have the client to agreed to resolve these issues before you start

Following these 5 points for my last 2 Citrix implementations, I’ve ended up finishing each project EARLY. I’d estimate my time spent on 🐵🐒biz is down from 50% to 30%.

As a result, I’ve got more time for the new items listed in the following pie chart:

1) Reviewing / improving the implementation
2) Providing hand-off docs to the client

Following an SOP that uses automation makes it easier for your co-workers to take over your work if you’re away on vacation/sick leave/etc. They can refer to internal docs / github to ID how you did your stuff, and if your automation uses logging (I hope it does) then ID when you did your work to the hhmmss 🙂

Now! I am just one person. In the comments, let me know how you do your own project work and/or any interesting examples of ‘monkey business’

Owen

One response to “Monkey biznuzz time mgmt startegy”

  1. Great article Owen! Definitely agree with getting the client to resolve issues identified early on but I feel like I’ve hit this road block so many times because I didn’t ask the right probing questions. Hoping to reduce the monkey business!

    Like

Leave a comment


Website Powered by WordPress.com.