Projects – The Merchant Stand

A tribute to the never ending projects.

You know those projects that seem to never end. The projects that extend well past their anticipated delivery dates. The projects that can’t catch a break or that can’t find sustained momentum. These are the projects that become the monkeys on our backs.

My experience is probably not so different from yours. There are projects throughout my professional career that I can describe with words like unlucky, doomed, slow, or unsupported. This isn’t necessarily because people dislike the project objectives. But for whatever reason, these projects stick in the portfolio and start to carry a heavier weight to the team that is involved.

Why do some projects hit their scope, timeline, and budget while others flounder?

I wrestled with this question after a discussion this week about the “monkeys on my back”. Thinking through my project experiences, several common themes were present with projects that failed to meet the original expectations of the stakeholders:

Underestimating the complexity – Team members and/or stakeholders underestimate the complexity required to complete a project. Software projects are prone to this issue if the project team underestimates the complexity of business process flows impacted by the software coding. It’s one thing to change code and make systems talk to each other. It’s another thing to consume the new changes and impact process flows of people and equipment.
Shifting the priorities – When a “more important” project takes team members away from an existing project then momentum is lost and work effort is delayed.
Staffing with the wrong people – Sometimes the wrong people are on the team to complete the job. This could be a skills gap for what is necessary to complete the requirements. But sometimes its about cultural fit between team members. Cultural is influenced by factors such as personalities, temperaments, and ideologies.

There isn’t a one-size-fits all answer to getting the monkey(s) off our back. But knowing why the monkey is there may help us to think of ways to get him off!

What are the origins of the phrase “Monkey on my back”?

I did some brief research and could not pinpoint the origin. If you know or find anything different on this let me know.

The 1854 edition of the Glossary of Northamptonshire Words and Phrases contains this:

“MONKEY. ‘I’ve put your monkey up,’ is a phrase implying, I’ve roused your spirit, or offended you. ‘I’ve put up your back,’ is an equivalent, which see. A child is said to have the monkey on its back, when in ill humour, or out of temper.”

The 1874 edition of the The Slang Dictionary contains this:

“Monkey, spirit or ill temper; ‘to get one’s Monkey up,’ to rouse his passion. A man is said to have his Monkey up or the Monkey on his back, when he is ‘riled,’ or out of temper; this is old, and was probably in allusion originally to the evil spirit which was supposed to lie always present with a man; also under similar circumstances a man is said to have his back or hump up.”

There are other passages where the phrase is used as a reference to being in debt with a mortgage.

In more recent times the phrase is used to describe a heavy burden or even a drug addiction.

This much we do know. We’d like to get those monkeys off our back. So take some time to think about why they are there. Then see if you can shake them loose.

Onward and upward!

Information Technology (IT) shops vary in size, budget, and processes. But all IT shops share a common set of challenges that shape how they interact with their inter-company customer base as well as the clients of their organization. There isn’t a single answer to these common challenges and they don’t disappear after a process is put in place to address them. In my own experience, I have seen these challenges in multiple business environments. The manner in which IT management chooses to respond to the challenges is interwoven in the culture, processes, and services of the group.

This is the first post in a series of writings to discuss issues facing Information Technology departments. These thoughts are more around framing the problem than presenting solutions.

IT creates and maintains technology platforms.

Challenge #1 – Project Work vs Production Support
The first challenge is how to concurrently allocate people for project work and production support work. Most IT shops are not blessed with a labor budget large enough to cover dedicated staff for each function. In general, production support will take precedence. At least for issues that create a system outage where orders or work is not processed. But what about production support requests for non-critical issues?

Example 1
Someone requests a modification to a report that requires a database administrator to adjust a set of SQL queries and alter the report format. The report is used internally and has been in-use for years. The new report layout is a preference of the requestor to make the output easier to read but the current report layout does not disrupt the workflow associated with the data.

At the same time the database administrator is asked to performance tune a set of queries for software code that is part of a new release.

Example 2
An inter-company department is moving to a new area of the building and creates a request to move PC equipment, configure departmental servers, and provide network connectivity.

At the same time, the infrastructure staff is asked to create and load a new test environment for the latest software program in the development area. The test environment requires network access, a web server, a database server and an application server.

The Challenge
The obvious challenge is to how to schedule these events when they require the same people and have the same requested due dates. What gets priority? At the root of this that production support requests are often unplanned or unknown until they are requested. Project work follows a more predictable request schedule because it is typically associated with a task on a project plan that is shared by the project manager.

The real puzzle is dealing with the unexpected while keeping the schedule of the known project work.

Is there some prescribed method to solve these dilemmas when they occur? Telling people there will be a delay is never an easy conversation to have. It’s a classic IT challenge. There are frameworks and processes. But each IT shop has a different amount of people and budget. So there isn’t a one-size-fits-all solution. IT staffers, management, and stakeholders must be flexible and patient.

Next week: Challenge #2 – Prioritizing Work

Tag Archives: Projects

Monkeys on our back

Classic IT Challenges – Project Work vs Production Support