Category: Project Management

How many projects does your company focus on at a time? For many companies, the number of active projects is often related to team size. How do you control, or at least manage this? What does that process look like? Do you use a tool, software, a manager, or something else?

The benefits of keeping control

What happens if you keep projects under control? While control is relative and may seem to consist of things not moving as fast as you’d like, it’s still critical.

“Control” does not demand a state where that things that look static, never changing, not growing, etc. Instead, we’re likely to see active projects where the mental headroom is available to thoughtfully consider the next step, much less the current one.

When that kind of space is available to teams working on a critical project, they tend to make fewer mistakes and overlook fewer things. These same things will be painfully obvious in hindsight.

A mind allowed some breathing room is less likely to work in a semi-constant distracted state where they’ll make mistakes, get injured, and / or overlook what will later seem obvious.

While it’s happening, it’s difficult to measure the cost of task switching and frenetic activity that comes having too many projects and too few hours / people to tend to them. What I tend to see from this is “doing 100 jobs poorly”. While your team might not be doing 100 jobs, they might be trying to do so many things that they don’t do any of them well. This damages your satisfaction with the quality of their work as well as theirs. These situations cause your team to do things a second time because they didn’t have time to do them right the first time.

Some iteration is a good thing, as our ability to provide a contextually accurate solution increases as our initial plan gets tested against reality. However, when the first iteration is almost always an attempt to check a box, the box really doesn’t get checked. That first iteration tends to be a solution that doesn’t satisfy your team or the client (internal or otherwise). Once you’ve trained your client not to bother implementing 1.0 of anything you create, it’s a tough place to battle back from.

We discussed the loss of trust a week or so ago. This is another type of trust – can your clients trust your new products, new services, new releases of software, new salespeople, new service writers, new mechanics, etc? When your project management and controls create a level of comfort for any or all of those new things / people / projects in your business, it creates a higher level of trust with everyone you work with.

How would your team benefit if they trusted each other more than they do now? How would your business, clients and partners benefit if your clients trusted practically anything or anyone new that you exposed them to? Same question – if your partners trusted practically anything or anyone new that your company exposed them to?

It’s not just a matter of quality and consistency. It’s a matter of what those things create. When you pay bills on time, people assume you’ll keep on doing that. When you don’t, it’ll take a while before paying them on time allows them to trust you.

What happens if you lose control?

While control is a bit of an illusion, seemingly out of control, frenetic behavior is fairly easy to see. If you aren’t careful, you’ll start seeing activity just so people can show that they’re doing something. Look at what’s being accomplished.

Inefficient activity often results from these situations. Have you ever gone to the grocery store without a list and found yourself bouncing all over the store as you think of the things you need? I remember as a kid that my mom grouped her grocery list by department, i.e.: produce, dairy, etc. While I’m not sure it sunk in while I was a kid, the benefits of that little effort on “elapsed time in grocery store” became obvious later in life.

Imagine a plane that gets to 80 knots on the runway and then decides to stop, change runways and take off again. It wastes a lot of energy starting and stopping, while getting little accomplished in the way of actual travel. Think of your projects in the same manner. Avoid changing runways.

A new project idea is always exciting. You think you have a great idea that’s going to take off in your market like gangbusters and you can’t wait to get started. In fact, the gravitational pull of this new bright, shiny object might be so compelling, you might discard all encounters with reality and start without doing any sort of market research, perhaps even setting aside real paid work that has stacked up.

As you might expect, I have another suggestion: use a concept called the minimum viable product (MVP), which is part of process called “Lean Startup“. While this originated in the software world, the process of developing a MVP can be used in ANY business.

Let’s talk about what usually happens to a new project idea.

New project idea development

While the minimum viable product concept took root in the software business, it can be used ANYWHERE.

Let’s take a brief look at the old way. I’ll discuss it in the context of the development of a software project, but this can happen during the development of any new project idea in any business.

The Lean Startup world relates primarily to software startups. Lean Startup recognizes the history of software project development over the decades and that it’s had a high failure rate. This failure rate quite often happened because software development often looks like this:

Software people get an idea

They determine what they believe to be the perfect solution and fall madly in love with it.

They run into a room for two years (or longer) to develop it, and work incredibly hard to produce this perfect solution to fit their idea or problem they’ve identified.

After years, they emerge, sweaty and victorious, having completed some portion of this perfect solution

These developers might emerge from their self-imposed development exile having become chest-bumpingly-giddy about their victory, only to find that they built something in a vacuum of customer feedback and the customer finds the solution misses the mark – often by a wide margin. Either it solves a problem the customers don’t care about, or it addresses a problem in a way that makes little sense to the customer, or the customer thinks it’s workable, if only the software people can make these 247 changes to how it works.

Making those 247 changes might take longer than the initial development, might cost more than the initial development, may not have management support, and idea doesn’t do much for a team of software people who became quite misty-eyed over the baby they worked on for the last few years.

Minimum viable product does away with running into a room for two years, and with creating what has universally become recognized as a danger to new and existing businesses: a vacuum of customer feedback.

Test, gather feedback, repeat

The Minimum Viable Product process is a rather efficient, mostly emotionless process for getting to the root of the problem and to the solution that best fits the customer. It looks something like this:

Talk to clients.

Build what you think they want – but build the smallest possible solution that emerged from the conversation about the problem or idea.

Place it in the client’s hands as soon as possible. If you can make this happen in two weeks or less, do so.

Watch them use it, ask them how they feel about it, ask them what they like, don’t like, hate, love, etc.

Go back to work, leverage their feedback and quickly make changes based on the discussions you had.

Repeat as necessary.

During your feedback sessions, ask them if they would pay real money for your solution and let them do so if they say yes. If they won’t pay for what you’ve shown them, you need to reconsider further investment in (or the direction of) the project.

Rather than two years (or some other long, expensive period) of product/service development, you might have two to four weeks invested. It’s better to find out that you’re on the wrong track earlier, rather than later.

For the last month or so, I’ve been working on an all-consuming project. Yesterday, during a conversation with the recipient of this work, it became obvious that both of us had made some assumptions about the work that overcomplicated the project in the short term. In the long term, no time was wasted on this large, multi-phase project but in the short term – the assumptions were stunning.

Despite hours of phone conversations and emails, detailed technical specifications (geeks: think WSDL but newer), we still managed to have a rather large gap in the workflow of this project. Fortunately, there wasn’t any damage done and the situation merely juggles the position of a few tasks on the timeline, but we didn’t have to be that lucky.

“Your assumptions are your windows on the world. Scrub them off every once in a while, or the light won’t come in.” – Isaac Asimov

The root of assumptions

The root of assumptions, at least in this case, was both groups of people thinking they had properly and completely described the project. Bear in mind that there are mindmaps and API calls and a bunch of other technobabble. Still, this happened.

But why?

Not enough questions?
Not enough diagrams?
Not enough workflow description?
Not enough conversation?

Perhaps all of those, but there have been plenty. What ultimately caused this was quite simple: there was a fundamental asset involved in this project that I was unaware of. They knew it would be used. I didn’t know it existed, so I was planning to use a similar asset under my control.

I speak vaguely about these things because the details really don’t matter and I don’t want the technical jargon to distract from the meat of the discussion: assumptions are dangerous.

The project will come in on time and it’ll be good for both parties, but it might not have worked out as well had this discovery happened a week later. It wouldn’t have broken anything, but it would have wasted some time, or at least caused work to be done that won’t be needed for a month or more and that would delay work needed soon.

There are many ways that assumptions can endanger your projects. The key is to have a process that does as much as possible to eliminate them.

Eliminating assumptions with a third party

The most dangerous assumption I made was that the technical documentation and the mindmaps would effectively communicate the project’s details to a technical audience. At a granular level that was true. Where this assumption got me was at the 10,000 foot level – the level where you break down a ton of technical workflow to 10 sentences (step 1, step 2, step 3…) in plain old English that anyone would understand.

Didn’t happen. Six weeks went by without this critical message climbing out of the technical documentation – and even then, it didn’t. It came out when those 10 sentences were written to clarify something that suddenly became confusing.

Many years ago, I was involved in an exercise along these lines where two people with experience in a field had to explain something to each other. Once they reached agreement, they had to explain it to a third person who had no background in the subject.

A fascinating thing happened.

The two people who thought they were describing the same thing were still far apart. When each of them described the project to the third party, they were stunned at the assumptions each of them had made – not big ones, not project killing ones, but differences that could create drama, friction, additional cost and so on.

Watching these two people realize they were not talking about the same thing was illuminating and stunning at the same time because the audience was made up of people with similar experience to the two ‘explainers’.

Of course, the exercise was designed to set them up to some extent and the whole idea was communicate to all involved that communication is real work and that it is breathtakingly easy to make a few small assumptions that can take two parties on substantially different paths even though they think they are talking about the same thing.

Getting two people (or two groups) to understand each other and agree that they are talking about the same thing requires great care.

Next time you have a project to deliver, involve a third party with much different skills. Describe the project to them and see where the conversation goes. Maybe you can avoid dangerous and potentially costly assumptions.

What are you not getting done? Why aren’t you getting those things done?

Does important work often go undone? If so, is that work truly important?

Delegation

Why aren’t you getting those things done?

Is it because of other things that keep you “busy”?

Are you busy because you aren’t delegating enough?

Are you unable to delegate?

Are you unable to delegate because you have no one to delegate to?

Are you unable to delegate because you don’t have time to document the task to be delegated?

Are you unable to delegate because the task requires skills that no one on the team has?

Do you have a system to develop people on your team? Is the system producing people that you can delegate tasks to?

If not, what should be changed so that the system produces team members who can take over the parts of your work that can be delegated?

Is it because you aren’t developing the “former” you in your team so that you can spend more time being the current you?

Systems

Is it because you don’t have an organized manner (system) of keeping track of what needs to be done?

Is it because the system (whether it’s paper, phone or computer-based) doesn’t work?

Is it because the system doesn’t work like you do?

Is it because the system doesn’t remind you of work that is scheduled or that needs to be done?

Is it because you don’t use a system that you have?

If you don’t use a system you have, why don’t you use it?

Focus

Is it because you aren’t giving yourself enough focus time?

What mechanism do you have in place to create focus time for yourself?

Does the mechanism work? If it doesn’t work, why is that?

Do others ignore the things you place in the way to allow you to have focus time?

If others ignore your focus time barriers, what have you done to clarify the situation or “discipline” those who ignore the barriers you build to create focus time? Are others aware of these barriers?

Classification

What is the cost of not getting these things done?

Is the cost, benefit or other financial impact what you use to determine the importance of a particular piece of work?

Does not getting these things done imply that they weren’t important after all?

Is the mechanism you use to identify work as “important” performing effectively?

If you look back at the work you considered important last month, do you still think it was important?

If not, how will you fine tune the system you use to assign importance?

Is there a system you use to classify work as important, not important, etc? One such system identifies work in four quadrants: “important and urgent”, “important and not urgent”, “urgent but not important”, and “not urgent and not important”. This system is often credited to “Seven Habits” author Stephen Covey, but there are also documents dating back to President Eisenhower’s use of the so-called “quadrant of work” system to decide what to do, what to decide upon, what to delegate and what to delete from the todo list.

Costs

Do sales or project goals depend on whatever you aren’t finishing?

Is the important work you’re not getting done tactical or strategic?

If so, is that a consistent situation? If not, have you recently been fighting through a situation that required you to focus on tactical?

Of the work considered important, is the cost of doing the work more than the benefit of doing that work?

If the cost exceeds the benefit, what makes that work important?

If the cost exceeds the benefit, should the work be done at all?

Turning that toward the less important (busy work?) that is consuming time best spent on the important work – if the cost of the busy work exceeds the benefit, should this work be done at all?

Do the important work

Consistently being able to identify the important and completing it while delegating what isn’t important IS the important work. The work you delegate may not be as important for YOU to do, but the fact that it can be delegated is the critical difference.

What’s the important work for you this coming week? What’s in place to make sure you get it done?

When I was young and a bit green at project management, I somehow managed to have responsibility for a number of big projects. Some came in OK, some never seemed to get rolling properly, some were late, and some seemed to take on a life of their own. A latter group tended to include projects whose scope was a moving target or had many unknowns.

The worst of these have a way of being the unknowns you never see coming, often gestated from a family tree of assumptions and incorrect or changed information.

Agile project management and related methodologies have helped a great deal. Many of these methodologies can trace their roots back to Lean manufacturing / management methods taught by Deming in Japan after World War II.

Success with these management strategies depends on early discovery of issues, challenges and changes in the information driving your decisions. This, along with our human tendencies, is why the MVP (minimum viable product) construct works. The earlier the customer sees your work, the earlier you’ll find out if you’re on track.

Usually, you get to decide how this discovery occurs: organically as the project work occurs, or in advance, thanks to discussions of expectations, requirements and manufacturing options during the design phase.

Poorly managed projects are often started without sufficient discovery and discussion. Even today, many projects are started and finished with very little advanced thought. No one would build an airliner as it rolls down the runway. While that sounds a bit ridiculous, this is exactly what happens.

The context of the design is critical as well. Work done in a vacuum, even with the best of intentions, often produces incorrect assumptions thanks to the aforementioned unknown unknowns. The project’s scope is an known unknown and the unknown unknowns are often a simple matter of lack of experience with the environment where the completed project will be used. The gap between expectations and results matters whether you’re building a crescent wrench, a software program or a Mars rover.

When will it be done?

While you may not have an accurate answer to that question, better design will improve your ability to give an estimate that someone can actually trust.

Better design? How?

The most common problem I see is not breaking things down into small enough pieces of work. Granularity is critical to the design and estimation of highly detailed / technical work. The volume of dependencies and unknowns in this type of work compounds the miscalculations and omissions resulting from a lack of detailed analysis, resulting in inaccurate estimates and missed expectations.

An estimate of days, weeks or months without a detailed breakdown of subtasks is symptomatic of the problem. I find that estimates require subtasks no larger than two to four hours to create a design that’s thought out well-enough to meet expectations, discover obstacles in advance, while producing a reasonable estimate.

But it’s not perfect!

Human nature also creeps into the equation: We like completing tasks.

It’s such a part of our us that people tend to focus on less important tasks simply because we can complete them before the end of the work day. We feel accomplished despite leaving big projects untouched.

If you’ve ever written things on a checklist that you’ve already done so that you could check them off, then you know what I mean.

Rather than fight the fixation on small projects that we can “download” and complete in a work period, feed it with subtasks of your big, important projects that conform to the need to complete something the same day.

Life has a way of being incredibly creative when it comes to finding ways to delay a project’s completion. Build these project management tactics into your design, estimate and build workflow so that you can get better work done faster – even on big projects.