Categories
Management Project Management Time management

The power of delegating

How much of what your company does absolutely MUST be done by you? How many hours a week do you spend doing those things? What if you could do 10-20 more hours of that per month. After a few months, what if you refined that new ability three or four times? Think hard about that. At that point, you would be able to spend 10-20 hours more per week on the things you and only you must do. How would that change your business? For that matter, how would it change your life? I learned this magic from a mentor who is pretty demanding about getting people to work on the things they’re best at – and nothing else. While not everyone can do that much delegating right off the bat, this process still leaves plenty of opportunity to gain valuable time to do the work no one else can do. 

Choose someone else

Perfecting the art of delegation (or at least refining it) is something that takes time. Identifying everything you do that can be done by others… doesn’t. If that seems tough, just identify the few things you do that no one, absolutely no one, can do for you. Now it’s easy: delegate everything else.

Yep, that simple. Start with the easy stuff.

Say you want to send flowers to your mom for her birthday. You can call the florist in the town where she lives and work it out with them. Maybe you prefer to call 1-800 whatever, or a local florist and ask them to make it happen. Or you can do none of that – and delegate the task to someone with as much or little detail as you like. Your mom doesn’t care that you didn’t make the phone call. She’s happy you remembered her and thought enough to send flowers.

You might be thinking “that was only 10 minutes on the phone”. Or 15. Or 20. Plus following up, if needed. Whatever. The time for this one task isn’t all that relevant. Look at the big picture and add them up. The point isn’t how much this one task takes. It’s about how many tasks like this are consuming your time each month.

Turn it up, by turning it around

Once you start getting into the groove of delegating, it’ll get easier over time. Thing is, there’s a way to completely rethink the process and realign how you look at new projects. When a new task or project pops up, think first about who else (ie: not you) can do the work – unless the work is on that (probably) short list of things that only you can do. Who else can manage it? Plan it? Track it? Lots of people, right? Let someone else do those things. They’re important, but that doesn’t mean someone else can’t do them. You focus on the portion of the project that’s work for you – and nothing else.

Multiplying the impact

Want to take this a bit further and multiply the impact? Start teaching it to your managers and skilled team members who get distracted / side-tracked by work that someone else could do.

You might be wondering “If everyone is delegating this work, won’t that require more people?” Yes, it might.

Thing is, if your managers and highly-skilled team members are doing enough of this work that it requires one or more people to complete it, that’s a problem. It means that your managers aren’t spending all of their time managing (hard to imagine, right?) Instead, they’re doing work that someone else can do. It also means your highly-skilled team members are spending an inordinate amount of time on things that other team members can do.

For managers, the problem is that when people, projects, relationships, and product delivery isn’t managed well, the entire company is affected. In the case of highly-skilled team members, we’re talking about high value, high cost, high return on investment work. Any time your highly-skilled team members are spending time on other tasks, they’re getting more expensive by the minute. Worse yet, they become more expensive when they spend time on random tasks that have nothing to do with their skill. Removing any non-core task from these folks increases their value and allows them to contribute more to the company’s bottom line. In some cases, this newly found time opens up sales opportunities because these folks can produce more of the thing you hired them to do.

Photo by Sayan Nath on Unsplash

Categories
Employees Management Project Management

Perspective and progress

As the end of the year approaches, it’s a natural time to look back over the past year’s work. Did you make progress? Was the year a success? The source of our motivation has a big impact on how we perceive the year’s work. Did I achieve a financial milestone? Will I get the leadership position I want? Did we reach our sales goals? These are external motivations. Internal motivations may also drive us – such as a need to learn, achieve, better yourself, make fewer mistakes, etc. Neither driving force is the wrong one. Personally, I think a mix of the two serves us well. As we walk the trail through our careers and personal lives, the source and makeup of what motivates us often changes. About 10 years ago, a mentor‘s comment completely changed how I relate to the things I achieve.

The gap on the way to ideal

When we look at our goals or ToDo list, 100% “perfect” completion of every single one on time and on budget is the ideal “destination”. While there’s nothing wrong with that, it’s rarely realistic. It’s also rarely necessary – at least on the first completion. 

First completion“? Yes, exactly. Few of us knock off a project and find that it’s perfect and never needs another polish, tweak, or modification. Even if the only customer is you, it’s better to complete the job, gather feedback and make another pass to improve your work.

The trouble with 100% completion is we rarely, if ever, achieve it. If 100% completion of your goals is consistently achieved on time and on budget, it often means the goals were watered down. We might extend a timeline, ignore some portion of the budget or loosen quality standards. Doesn’t matter which one.

Looking back at the Apollo project, NASA was charged with getting men safely to the moon and back by the end of the decade. I remember watching the first steps broadcast on a grainy black and white TV at my grandparents’ farm. That was a late night for a young kid in 1969. Yet Apollo wasn’t 100%. An Apollo I launch rehearsal cost the lives of three astronauts. Apollo 13 almost did the same while traveling between Earth and the Moon. NASA achieved the audacious goal Kennedy laid before them, despite not achieving perfect execution. 

The gap between perfect execution and your actual execution is quite often significant. Having the right perspective is critical. 

Perspective and the gap

When we look at the ideal outcome, we’re almost certain to come away disappointed. We expect perfection.  You won’t be happy or satisfied with your efforts when you assess where you are against where you expected to be when everything went perfectly. That space will be filled with regrets about incomplete tasks, tasks that weren’t started, things that didn’t go as planned, etc.

The comment from my mentor paraphrases like this: If you look forward to the difference between what you did and the ideal outcome, there will always be a gap. That gap will always bother you – and it destroys the ambition in some. However, if you look back from where you are to where you started, you’ll find great satisfaction and motivation to charge forward when seeing how far you’ve progressed.

This change in perspective completely changed how I felt about the incomplete / untouched items taunting me from their comfortable home on my Trello board. Strive for 100%. Celebrate your progress, however imperfect. Use your progress as motivation. Keep improving. 

Perspective destruction

When a team’s original goal appears to be within reach, managers often trot out “stretch goals”. Is this done to create a failure that can be held over a team? Stretch goals usually create morale failure from significant progress. Motivation is rarely the outcome. Managers should focus on the 90% your team achieved, rather than the 10% that didn’t get done. It seems natural to do this when you’re a software guy – since we often focus on what’s broken. As a leader, it seems like a great way to repeatedly chip away at the morale of your team by never letting them celebrate or acknowledge accomplishments. The time to focus on the 10% will come soon enough. 

Categories
Employees Management Project Management

Driving hard at stretch goals

A couple of months ago, I was driving to Banff to meet some friends in a rig we call the Scoutmobile. About an hour into the drive, the engine’s temperature started heading into risky territory. I was in an area where there was very little room to pull over, so I started looking for a safe, roomy place to get off the road. In management-speak, this would be a stretch goal.

While searching for a place to stop, I used common engine overheating delay tactics: turn on the heat, slow down, etc. I had a simmering suspicion that a blown head gasket was coming home to roost. This rig had close to 300K miles on it, so this wasn’t an outlandish possibility. As this suspicion moved toward reality, it was obvious that simple overheating delay tactics wouldn’t help for long. I needed to stop.

Stretch goals and context

Getting to a safe, roomy stopping place became a new and much smaller stretch goal because the context changed. Frankly, making the 400 mile drive to Banff and getting back without mechanical trouble was really the stretch goal. Given the rig’s mileage and concern about the head gasket, I had wondered for months if it would survive the trip.

Once the engine temperature started rising, my decision making context changed. Meeting friends in Banff was off the table. Finding an ideal place to pull over became the stretch goal. Getting off the road was possible, but not quickly. Leaving the road in a nice wide spot so I wouldn’t cause traffic issues became the stretch goal. 

As I finally rolled into a safe spot out of traffic, the engine lost the little remaining power it had and locked up. The first time it stranded me in 17 years turned out to be our last drive together. While I made the stretch goal even in the altered context, even that seemingly tiny stretch goal was too much for the situation. That’s the lesson here – attention to changing context is critical.

Stretch goals aren’t the problem

I don’t mean to say that stretch goals are bad. They aren’t, but context is critical. When my trip’s decision making context changed, so did my goals for the day. Looking back, it’s possible that stopping immediately would have prevented the locked up motor. I didn’t want to partially block a lane on a two lane highway. That as my justification to push a little bit further – a stretch goal. 

When you decide on stretch goals, be sure you aren’t going to drive your team too long at “redline”. Redline (in automotive terms) is the maximum speed at which an engine and its components are designed to operate without causing damage to the engine.

Making your monthly sales goal in three weeks is a classic time to give your team a stretch goal for the month. Adding requirements to the final days of a project that’s already behind will all but guarantee late delivery. Likewise, shrinking a timeline they’re already likely to miss is a good way to sour a hard-fought win.

Race drivers will repeatedly push a race car’s engine to or a bit beyond redline because that’s when they get the most from their engine. Thing is, they won’t do it for long. Pretty soon, they’ll shift or brake. They know redline is there for a reason and pushing the engine beyond normal operating limits for too long will end badly.

Running at redline

Prolonged running at redline has similar effects on people. Someone can work a couple of 80 to 100 hour weeks under near-term deadline conditions and some will do so willingly if they believe in the goal. 

Where this goes bad is when it becomes “normal” to work like this. Do this and some (probably all) aspects of their lives will suffer. They’ll not have (or make) time for family, or taking care of themselves. Eating and exercise habits will suffer. They’ll have less (or no) time for friends, the dog, yard, car, hobbies, etc. Rest will suffer, so their ability to focus, concentrate and show patience will be affected. Burning bridges at home combined with a drop in work quality / output can permanently create morale / attitude problems. 

Sometimes limits really are limits. Exceed them too often for too long and you’ll damage engines, people, relationships and before long, your company. 

Categories
Business culture Management Project Management

Three things or seventy three

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.

Photo credit: https://www.flickr.com/photos/kija_kaji/

Categories
Entrepreneurs Project Management Small Business Strategic Notepad

New project idea? Do this first

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.

Want to learn more about this process? There’s a free course at Udacity that will take you through the process and teach you how to do it yourself. https://www.udacity.com/course/how-to-build-a-startup–ep245 

You don’t have to be a startup to use this process. It works for any project.

Categories
Customer relationships Project Management Setting Expectations Small Business

Assumptions are dangerous

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.

Hat tip to @ClayForsberg for the Asimov quote.

Categories
Entrepreneurs Leadership Management Project Management Small Business

Complete the important work

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?

If you don’t have your system fine tuned yet… Does your staff?

Categories
Competition Improvement Leadership Management Project Management Setting Expectations

Project Management: Is it done yet?

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.

Secretary of Defense Rumsfeld famously said that decisions are made while dealing with “known unknowns and unknown unknowns“. Anyone with large project experience knows exactly what he meant. Interestingly, Rumsfeld credits a NASA manager with the terminology.

Project management requires discovery

The software business has a sketchy reputation for delivering projects on time, despite a lot of internally-driven improvement over the last two decades. This reputation is sustained by the memory of failures of very large software projects.

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.