Work-scheduling algorithms have been around for years. First in, first out (FIFO), for example, is a common approach when all work is considered equal. The brilliance of FIFO is that it contains both the start criteria and the completion criteria as well as the implicit assumption that a customer is anxiously waiting for delivery. After all, no customer wants to hear that some other customer jumped in front of them in the queue.
When it comes to starting and finishing internal projects, on the other hand, most organizations operate with a two-level prioritization approach. At level one, the organization will develop a rank-ordered list. Then, the real prioritization happens.
Ideally, organizations should be taking the projects in priority order and fully staffing them to ensure the earliest possible completion. Instead, projects are only partially staffed to increase the number of projects that are in flight at the same time.
As an ex-CFO, I’ve never heard an explanation of this practice that makes sense to me. It’s expensive—not only in terms of total hours worked (the task switching penalty), but also in terms of duration—which ultimately delays the benefits. It also leads to unnecessary stress on the workforce, and my gut tells me it increases technical debt, which will eventually cost more time and more money.
Prioritizing and planning
How can we fix this? The trick is to SHOW project requestors when their projects will be completed based on developing a good-faith workable resource capacity plan. Therefore, getting the right software in place (i.e., something other than excel) is the first requirement.
The second requirement is to make a conscious decision about which projects need to be done first. Politics aside, there are generally only two reasons to put projects at the front of the line:
- There’s a measurable value that the organization will receive once the project is done.
- Other future projects are dependent on a particular project being done.
In both cases, the speed at which the project gets done is important.
The third requirement is that these projects need to be staffed for speed. That means they need the right people.
Building a project team used to be an art. A project manager knew what project areas were risky and concentrated on getting the right staff to mitigate those risks.
Not to mention, assigning someone to a critical role without first vetting that they have the skills and knowledge to do the job can destroy the timeline for the entire project. It could take multiple interviews to get to the right person who not only had the skills, but would also blend well with the other team members.
The power of deep knowledge
I once ran a program that was the third try for the company. The previous two times, they’d tried to run it internally with only their resources. This time, the CEO stepped in and demanded it get done and get done right.
The program had a single massive technical risk, so finding someone with knowledge of the risk area was critical. Luckily, the company’s internal network quickly surfaced a senior technical person halfway across the country who, according to people who knew him, was the world’s leading expert on the subject. He also had a reputation of being extremely difficult to work with.
Though no one ever admitted it to me, I’m 90% sure the reason I was asked to manage the program was solely based on the belief that I would not butt heads with our senior technical resource. So, not only did this program require the right technical person, but it also required the right program manager who could effectively team with the right technical person.
We reached the last milestone, turned the switch, and our worst fears were realized: it didn’t work.
Of course, Murphy’s law meant it was also the week the project’s in-house expert was literally out at sea and unreachable. We had to call in every other “expert” in the company, but everything they tried failed.
On Monday of the following week, the in-house expert returned, and the problem was solved in 10 minutes. Twenty brilliant minds in a conference room for a week couldn’t solve what turned out to be a simple database setting. Of course, our in-house expert’s knowledge was based on years of intensive study of just the type of problem we ended up having.
Cataloging deep knowledge
Getting the right person to the right project is not just a mantra. It’s an important reality, especially if the goal is being done as quickly as possible. That’s why organizations must invest in a skill and knowledge system.
The technical genius I had on my program staff would have shown up in most systems with a competency of Guru. He had published a book on the subject, which was a requirement for a top competency rating at our company.
But how many systems would have captured his equivalency of 10,000 hours of deep study on exactly how the technology we were using worked? He had tested things on his own time to see what would happen under various scenarios simply because he wanted to know.
Every company has their equivalent staff members, the ones who have deep knowledge of subjects. And almost every company thinks it doesn’t need to know about this deep knowledge… until, of course, it does.
I’ve occasionally asked companies why they don’t bother capturing that knowledge about their people. Usually, the answer is: “then they’d think they are special, and we can’t afford special people.”
Having spent several decades involved in managing projects and programs, my answer has always been: “how can you not?”
CEOs want agility. Agility requires getting things done rapidly. Getting things done rapidly requires the RIGHT people assigned to the right work.
Luckily, in today’s world, software can help achieve what human effort alone often fails to accomplish. Software that captures people’s skills as well as deep knowledge makes it possible to assign the right people the right work for the right amount of time.
