
🐵
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:
- Client not having DHCP setup anywhere in their environment, which meant my beloved packer automation would not work
- Worse, Extra DHCP servers authorized in AD that have bad scope options set that provide incorrect DNS info
- Citrix Hypervisor (XenCenter) any $ you saved on using Citrix HV instead of a proper hypervisor like Nutanix / VMware , will certainly be lost to troubleshooting efforts / downtime down the line
- Messy AD environments, clients still using FRS , clients who’ve not updated ADMX templates in 10 or more years
- In-house apps that require manual efforts to get working on newer OS versions: Win 1x, Win Server 20xx
- Lost private keys to TLS certificates
- Internal windows update servers running against new OU’s , and no-one has access to manage the servers to stop it from happening
- Incorrect licenses purchased: ESXi, Nvidia, RDS, etc
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
- 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 - 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
- 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
- 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
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!
LikeLike