Author: Fergus

The 4 Types of Project Manager

The 4 Types of Project Manager

Earlier this year, the Harvard Business Review published an article called The 4 Types of Project Manager. The article described how different types of growth opportunities require different types of project managers to run them. It’s a good article.

It’s been my experience that there are indeed four types of project manager – though in a different way from that described in the HBR. The four types are:

  • The Techie
  • The Pioneer
  • The Magician
  • The Soothsayer.

The Techie

We need techies. There would be no projects without them – both the ones who conceive a grand vision and the ones who work to deliver that vision.

In many organisations – though this is changing – it can happen that there is only so far a techie can go in terms of increased salary and promotion. To get round this problem, techies are often promoted to manager – and therein, potentially, lies a problem.

Often too though, it has to be said, the techie who conceived the grand vision wants to be the one who delivers it i.e. the project manager. Therein too, lies a problem.

I’m not saying the great techies can’t become great project managers, but to be honest, I haven’t seen it very often myself. The things that excite a techie are not the things that excite a project manager. I’m a project manager. Show me a beautifully estimated Gantt Chart and it will bring a tear of happiness to my eye. Show it to most techies and they regard it as ‘admin’.

The Techie (i.e. a techie who has become a project manager) often has no interest in the ‘things’ of project management – tasks, people, dates, effort and so forth. Techies bring everything back to technical matters. Try to talk to them about project management ‘things’ and their eyes quickly glaze over and you can tell they’ve stopped listening.

(Gently and tactfully) offer to educate them in these matters and they’ll say yes – but it’s a ‘yes’ that’s actually a very definite ‘no’. Technical matters are where the Techie is comfortable; they will almost never step outside their comfort zone.

Often the Techie has no little or no interest in work-life balance – at least, while the project is going on. The Techie reckons that almost all problems on the project have a technical solution and those that haven’t are ‘HR issues’.

Techies generally tend to look for complicated solutions and the notion that there might be a simple, common sense solution is abhorrent to most Techies.

If you’re persuasive enough or failing that, lucky, you may be able to get a Techie to produce a plan for you. The Gantt Chart they give you will almost certainly be a timeline (i.e. without estimates of effort) – probably produced in something like Basecamp or whatever the latest hot thing is.

A Techie project manager may or may not deliver a project. If they do, it will usually be after much blood, sweat and tears that probably could have been avoided if some basic planning had been done.

Techies – gotta love ‘em! There’d be no projects without them.

Most likely to say: ‘We don’t have time to plan it – just go do it!’

Least likely to say: ‘Just give me a few more minutes – I want to get this status report looking absolutely right.’

 

The Pioneer

The Pioneer is most often found in companies that were once startups but that have now been on the road for a few years. Generally, in such companies, the Techies (techies who have become project managers) rule the roost.

The Pioneer arrives on the scene convinced that there’s a better way to deliver projects.

The Pioneer has often attended some kind of project management course or read a project management book and has had a Pauline conversion to the whole idea of good planning.

It’s tough being a Pioneer. I say this having been one.

The Pioneer has to carry out a constant fight against the ‘We don’t have time to plan it, just go do it’ brigade.

The first time a Pioneer tries to sell a realistic plan to bosses or stakeholders or customers, they [the Pioneer] will face a barrage of criticism. Phrases like ‘That’s not the culture here’ or ‘Is this plan based on a 5-day week?’ or ‘If you don’t do it, I’ll find somebody who will’ or much worse, will be traded freely.

This may well continue over the life of that first project.

But there’s good news for Pioneers. The first project you work on will be the hardest. It get’s easier after that and over time – if you stick to your guns – you may be able to leave your pioneering days behind and become a Soothsayer (below).

Pioneers will pretty much always deliver their projects – that’s if they don’t quit first!

Most likely to say: ‘I won’t be able to tell you until I’ve done a plan.’

Least likely to say: ‘Sure.’

 

The Magician

Magicians do exactly as the name suggests – they do magic tricks; they take seemingly impossible projects and make them happen. When a boss says, ‘If you don’t do it, I’ll find somebody who will,’ the somebody they are referring to is a Magician.

If a company has Magicians, it should love them. It should give them bonuses, stock options, profit-sharing, promotions, extra grades, flowers on their birthday, presents at Christmas – because Magicians do an extraordinary thing.

Imagine you went to a job interview and the interviewer asked, ‘What do you do?’

‘I do impossible missions,’ you reply.

The interviewer’s gonna say, ‘Sign the contract. How much do we have to pay you to come and do that for us?’

But there is a problem with being a Magician – and it’s a very serious problem.

As soon as you do your first magic trick, as soon as you pull that first rabbit from the hat, you’ve now created a problem for yourself. Now, a rabbit from the hat is suddenly the standard that bosses / stakeholders / customers expect.

This means that the next time you go on stage – the next time you have to do a magic trick – a rabbit from the hat won’t impress anybody; you’ll have to do a bigger animal.

The result of this is that you now suddenly find yourself on an escalator that only goes up and every time you do a more spectacular magic trick, that becomes the new standard that everybody expects.

While all of this is going on, you and your team are now probably working insane hours with all the attendant problems that come with that – health, relationship, quality of life – not to mention that fact that working long hours for sustained periods of time quickly becomes unproductive. (To be clear what this means – you would be better off working your team forty or so hours a week and sending them home to have a life.)

There’s a saying that ‘All political lives … end in failure.’ This is almost always true of Magicians as well. Sooner or later our Magician take on something that is actually impossible and the project ends in tears at bedtime.

Usually then, the Magician leaves that organization and goes to some place new. Will they have learnt from this bitter experience? Probably not? Most Magicians revert to type and start doing low-grade tricks again – pulling small furry animals from hats! But all they do is get on the escalator another time.

A Magician may or may not deliver a project. If they do, it will usually be after epic amounts of blood, sweat and tears that could certainly have been avoided if some basic planning and subsequent negotiation with the powers-that-be had been done.

Most likely to say: ‘Sure.’

Least likely to say: ‘No.’

 

The Soothsayer

The definition of a soothsayer is ‘a person able to foresee the future. This IS what Soothsayer project managers do – they predict the future and then make it come true.

Soothsayers build proper plans. Using these plans, they then tell bosses / stakeholders / customers what’s possible and what isn’t. They do this in a calm, unemotional way using the facts in the plan as evidence.

Soothsayers know that they know more about the project than anybody else. Thus, if a boss / stakeholder / customer says that the Soothsayer is wrong or hasn’t thought of something or has the wrong end of the stick, the Soothsayer will politely correct them and show them the error of their ways.

When bosses / stakeholders / customers engage in delusional behaviour – for example, saying non-fact based things to the project manager like ‘You’ve got to find a way’ or ‘You’ve got to work smarter, not harder’ or ‘If you don’t do it, I’ll find somebody who will’, the Soothsayer politely but firmly brings them back to reality, to the world of numbers and facts.

As somebody once described it – and in some ways, I have yet to find a better description – ‘[Soothsayers] take no crap from the management.’

Soothsayers are good people because they stop bosses / stakeholders / customers from doing harm to themselves.

Soothsayers don’t ‘say no’ or ‘push back’. In a very real sense they don’t bring problems, they bring solutions.

A Soothsayer will always deliver a project. And then another. And another and another. What Soothsayers do is sustainable. They build a track record of success, while having a life outside work – which is as it should be.

Most likely to say: ‘Here’s why that won’t work but here’s what you could do.’

Least likely to say: ‘Sure.’

 

 

—o0o—

 

If you found this useful, please share it with anyone else you know who’s trying to get projects done successfully.  

 

13 Signs That Your Project May be In Deep Trouble

13 Signs That Your Project May be In Deep Trouble

Obviously, the only way you can know for sure whether your project is in trouble or not is to (a) have a properly estimated plan and (b) be monitoring properly against it. Those issues are discussed elsewhere on www.fastproject.org.

However, there are a number of signs I have seen over the years which are guaranteed to raise the hairs on the back of my neck and may be indicative of major trouble.

Since some of these are not exactly objective or measurable, I’ve tried to give an indication of how reliable they might be.

 

1 No Plan

No plan at all. Or a poorly estimated / sketchy plan.

Probability that the project is in trouble: Certainty

 

2 No Effort in the plan

The plan is actually a timeline. It doesn’t contain estimates of the amount of work to be done (Effort).

Probability that the project is in trouble: Medium High. Also very likely that people are working very long hours in order to stick to the timeline and keep the project on schedule.

 

3 Stories

Stories are great in novels or in movies; they’re generally very bad in projects. If you (a) ask the team what the project is about or (b) ask to see a copy of the plan or (c) ask for the status (especially this) and they give you a story: ‘This happened and then that happened and then so and so did this and that person went there …’

Probability that the project is in trouble: High.

 

4 GGGGGGR!

No, it’s not an expression of frustration or anger – though if this happens to you, you’ll be frustrated and angry and probably a whole lot more.

It’s when a project manager reports a project Green – On Target, week after week and then suddenly jumps out of the cake and announces that it’s Red – In Big Trouble.

Probability that the project is in trouble: Very High – Certainty. This project should be the subject of forensic examination to determine what’s going on. If it were me, I would also tell the project manager that if s(he) ever did anything like that again … well, you know!

 

5 No status reports

Assuming that (ideally, weekly) status reports have been issuing, if the project manager misses a week, I’d be very concerned. If they miss two weeks in a row, my experience has been that it’s a certainty that the project is in major doo-doo.

Probability that the project is in trouble: Missed 1 week – Medium. Missed 2 weeks in a row – Certainty.

 

6 ‘Everything’s under control’

You ask the project manager the status of the project and this is the answer you get.

Probability that the project is in trouble: Medium. My experience has often been that everything’s not under control.

 

7 ‘This is a very aggressive schedule’

Somebody – usually a boss, very senior / important boss, stakeholder, project sponsor or customer – says this.

Probability that the project is in trouble: For me personally in my career, this has proven to be a Certainty. My experience has been that anyone who says this has usually parted company with reality. To be balanced though, let’s call it High.

The good news though, is that it’s often said at the beginning of projects and so you have the chance to do something about it before it grows into a nightmare.

 

8 ‘We have a high level plan’

You ask whether a project has a plan and this is what you’re told.

Probability that the project is in trouble: Certainty. In my experience this means the project has no plan to speak of.

 

9 Heavy multitasking

The organization is one where people are doing lots of multitasking i.e. they’re spread across many (i.e. more than a handful of) things.

Probability that the project is in trouble: Medium High. Also very likely that people are working very long hours in order to stick to the timeline and keep the project on schedule.

 

10 ‘We’re 90% done’

The terrifying ‘we’re 90% done’ which usually means that 90% of the scheduled project time has gone – not that 90% of the thing has been done.

Probability that the project is in trouble: Medium High.

 

11 ‘We don’t have time to plan it, just go do it!’

Somebody – usually a boss, very senior / important boss, stakeholder, project sponsor or customer – says this.

Probability that the project is in trouble: High.

The good news though, is that it’s often said at the beginning of projects and so you have the chance to do something about it before it grows into a nightmare.

 

12 ‘Great!’

You ask the project manager the status of the project and this is the answer you get.

Probability that the project is in trouble: High if it’s accompanied by any of these http://uk.businessinsider.com/how-to-tell-someones-lying-by-watching-their-face-2016-1. Probably good to know about these anyway!

 

13 ‘You’ve got to work smarter, not harder’

Somebody – usually a boss, very senior / important boss, stakeholder, project sponsor or customer – says this to the project team. (Usually at a time when the team is already working crazy hours anyway.)

Probability that the project is in trouble: High.

 

 

—o0o—

 

 

 

 

 

 

 

 

How to Estimate Anything Accurately

How to Estimate Anything Accurately

Okay, so hopefully we’ve established http://fastprojects.org/2017/08/23/we-dont-have-time-to-plan-it-just-go-do-it/ that planning is a good idea and that the alternative – ‘we don’t have time to plan it – just go do it’ is, to put it mildly, rather dumb.

But how can we estimate accurately when estimation is – basically – predicting the future and something that no mortal person can do? There are three things that can help us. These are:

o Detail in the plan
o Learning from previous projects
o Using Assumptions.

We have a paper called How To Estimate Anything Accurately. If you’d like a copy just email us at info@fastprojects.org and we’ll send it to you.

‘We don’t have time to plan it – just go do it!’

‘We don’t have time to plan it – just go do it!’

Don’t know if you’ve ever heard somebody – typically, a boss or a manager – say ‘we don’t have time to plan it – just go do it’. And maybe you’ve wondered if this is good advice / a good strategy / good management practice. After all, they’re probably more senior to you, more highly paid, more experienced, more knowledgeable.

Well, here’s what cooking dinner would be like using the same ‘we don’t have time to plan it, just go do it’ approach.
Imagine this. It’s about six o’clock in the evening and you suddenly realise you’re hungry. You decide to cook dinner.

Here’s what you do next:
1. You light the gas ring.
2. You look in the fridge to see if there’s something to cook.
3. You find there’s nothing you like there, so you decide to head down to the supermarket. Hopefully, you turn off the gas ring before you go.
4. You return with some eggs. You’re going to make an omelette.
5. You light the gas ring again.
6. Where’s the frying pan? Uh oh, it’s in the dishwasher and the dishwasher is part way through its cycle. Okay, let’s wait until the cycle is over. Turn off the gas again. Go watch TV.
7. Finally the dishwasher cycle is over and you starting cooking your omelette. But then you think, ‘It’d be really nice to have some fried potatoes with the omelette.’ But oh hell, you should have done the potatoes first because they take longer than the omelette.
8. You finish the omelette and put it in the oven to keep warm. You start on the potatoes. You’re going to have a can of mushy peas with them and happily, you have both enough potatoes and the mushy peas.
9. But mid way through frying the potatoes, you change your mind. Wouldn’t asparagus be really nice instead of mushy peas? Back down the store again.
10. And so on …

Good advice / a good strategy / good management practice? What do you think?

How to Shorten a Project #1 – the Quickest Win of All

How to Shorten a Project #1 – the Quickest Win of All

If you want to shorten a project there is one place where – more than any other – this can be achieved.

This is right at the beginning, as soon as the idea for the project is born.

You don’t have to take my word for this.

In their book, Developing Products in Half the Time , the authors Smith and Reinertsen refer to the beginning of the project as ‘the fuzzy front end’. They say this: ‘Time is an irreplaceable resource. When a month of potential development time is squandered, it can never be recovered … each month of delay has a quantifiable cost of delay. Our goal as developers is to find opportunities to buy cycle time for less than this cost. These opportunities, large and small, appear throughout the development process. There is, however, one place that we could call the ‘bargain basement’ of cycle time reduction opportunities. It is the place that we consistently find the least expensive opportunities to achieve large improvements in time to market. We call this stage of development the Fuzzy Front End of the development program. It is the fuzzy zone between when the opportunity is known and when we mount a serious effort on the development project.’

If the ‘fuzzy front end’ is where ‘opportunities to achieve large improvements in time to market’ are greatest, then learning to scope and plan a project in a day is the best way of maxing out those opportunities.

If you don’t scope and plan the project in a day, what’s the alternative? It goes something like this:
1. Somebody identifies some kind of need or requirement or problem that needs to be solved.
2. Based on this somebody does some ferreting around and then writes a proposal / business case / specification.
3. This is reviewed by the stakeholders (those people affected by the project) and the reviews are fed back to the author of the document.
4. There are updates to the document, plus perhaps flurries of e-mail exchanges, phone calls, requests for information and meetings to resolve various issues.
5. Items 3 and 4 get looped around a number of times until finally …
6. There is agreement on what we are going to do.
7. Then somebody is charged with building a plan.
8. That somebody does some ferreting around and then writes a plan.
9. That plan is reviewed by some or all of the stakeholders and the reviews are fed back to the author.
10. There are updates to the plan, perhaps more e-mails, phone calls, requests for information and meetings – particularly if there is a gap between what the stakeholders want and what the project team say is possible.
11. Items 9 and 10 get looped around a number of times until finally …
12. There is agreement on the plan.

This process can take weeks … months … years, in some cases.

As an alternative to all of this carry on, you can scope and plan the project in a day.

Affected by Brexit? You’re gonna need this

Affected by Brexit? You’re gonna need this

It’s the classic situation that all project managers find themselves in, sooner or later. The deadline is fixed but the requirements still haven’t been decided. Every day that passes is a day lost than can never be recovered.

But this time it’s different. This is the true nightmare scenario.

There isn’t just one project – there’s a whole bunch of them. And worse – they’re all happening in parallel.

If this is you then you’re going to need to do some new things that you haven’t done before.

So here – for openers – are three things that will help you. You can do them now, straight away.

 

1 Learn how to estimate properly

If you can’t estimate a project properly then you’re probably doomed from the outset. You’re like someone who sets out to cross a desert not knowing how wide it is. Will you get to the far side? You might. You might also find that you’re part way across with no more water and no idea how much of the journey remains.

Next week we’ll tell you how to do this.

 

2 Learn how to scope and plan a project in a day

At the beginning of a project is where the greatest opportunity to accelerate it is.

Imagine what it would be like if – on day one of the project – you could scope it, plan it and launch it i.e. allocate jobs to people and have it up and running.

You can be skeptical about this if you like but it’s entirely possible.

 

3 Stop multitasking (for goodness sake!)

Multitasking is catastrophic for productivity http://fastprojects.org/2017/06/23/multitasking-is-disastrous-for-productivity-so-why-does-everybody-do-it/. Stop it.

Instead:

  1. Make a list of the projects that have to be done.
  2. Prioritize the list.
  3. Flood the most important one with resources to get it done. Do this with the next most important one, the next most important and so on.
  4. Do this, even if it means not starting some projects just yet. You will still get them done quicker than if you had been multitasking.
  5. As soon as a project completes and its resources free up, move them to the next project on the list.
  6. Eat up the list of projects in this way.

 

—o0o—

Increase the Bottom Line for Free? No Thanks

Increase the Bottom Line for Free? No Thanks

You would have thought that if you told most bosses or CEOs that there was something they could do which would:

  • Save precious time which could then be used for other things
  • Reduce costs
  • Reduce waste
  • Save money
  • Increase revenues
  • Increase profits
  • Improve cash flow
  • Enable them to steal a march on, or gain a competitive advantage over their competitors
  • Deliver business benefits quicker
  • Reduce the risks of projects running over time or budget
  • Increase staff morale
  • Give greater employee job satisfaction,

they would jump at it.

If, in addition, you told them that this would require no extra resources – material or people, then you’d have thought the only question would be, ‘ How soon can I have it?’

Bizarrely, this is not the case.

Shortening projects / shortening time to market is something that does indeed tick all of the boxes above. Nor does it require extra resources – merely a change to the way the current resources are used.

Why then, is everybody not trying to do it?

It seems to me that there are a variety of reasons:

  • People don’t actually believe it’s possible – most bosses and project stakeholders think they’re lucky if projects come in on time and within budget.
  • Nobody figures out what getting the project done early would mean financially.
  • Many projects aren’t planned and estimated properly – if they’re not planned and estimated properly they can’t possibly be done quicker.
  • Getting projects done quickly is not in the ‘official’ project management literature, the Project Management Institute’s PMBOK [Project Management Body Of Knowledge].
  • The emotional investment people have in the way things are done at the moment – ‘What’s wrong with the way we do things at the moment?’ syndrome.
  • All of the people involved in the project are afraid that if they do the project fast they’ll miss something important.
  • Especially in high-tech organizations, very smart people can often regard very simple ideas as being of no value.
  • Again in high tech organizations, very smart people often can’t believe that simple ideas would work where complex ones have failed.

It’s a pity – because for those bosses and project stakeholders who are going to be first to embrace this disruptive idea, there will be a crock of gold at the end of the rainbow.

 

 

Need More Contingency? Run a Fast Project!

Need More Contingency? Run a Fast Project!

Of the many benefits of running a fast project, a somewhat unexpected one is what it can do to your store of contingency.

Contingency is one of the more troubled areas of project management. Sensible industries – such as construction, for example, or filmmaking – expect to see contingency in a plan. Then, there are industries – most high tech industries are guilty here – where if bosses or customers or project stakeholders see contingency in a plan, they’re more than likely to take a red pen to it, draw a line through it and say, ‘Well that can come out for starters’.

But contingency is essential in a plan. It’s essential because it’s tied to the crucial question of change control.

When a change occurs on a project there are only ever three ways you can respond to that change:

  1. You can say, ‘Hey, that’s a big change. That’s not what we originally agreed.’ Changes to project scope, changes to resourcing and assumptions turning out not to be true – these are big changes.
  2. If something isn’t a big change, you can use the contingency (provided you have some).
  3. If something is a big change, but you don’t have the guts to say that to the people for whom you’re doing the project, and there’s no contingency in the plan, either because you never put it in in the first place or you did, but then some idiot took it out and you didn’t stop them, there’s only one other possibility when changes occur and – quite simply – that’s to suck it up. Work nights, work weekends, bring work home with you, phone up your significant other and say ‘give my dinner to the dog, I won’t be home tonight’ and so on.

If you have no contingency in your plan, you’re reduced to two options – either something’s a big change or you’re going to have to suck it up. To put that another way, your plan can now only succeed with some level of sucking it up. The problem with that, of course, is that there’s a limit to how much sucking it up you can do. There are only 24 hours in a day, 7 days in the week, and a finite number of people on your team.

All of which brings me to running a fast project. One of the really nifty by-products of running a fast project is that it generates contingency. Each day you save is a day you can add to your store of contingency. This has four effects:

  • If you started out with no contingency, you now suddenly have some.
  • It reduces the likelihood that your project is going to run late.
  • It gives you more wiggle room if you get unexpected surprises late in the project.
  • It means that when some unexpected big change does occur – especially late in the project – you may be able to say to your stakeholders that this is one you can ‘absorb’ i.e. you’re not going to hit them with a big change.

It used to be that there were only two options where contingency was concerned – put in explicitly (and run the risk of the stakeholders whipping it out) or hide it so they couldn’t find it. With fast projects you have a third option – you can generate it as the project unfolds. Nice!

Why Do Our Projects Take So Long? Because We Don’t Care Enough

Why Do Our Projects Take So Long? Because We Don’t Care Enough

Picture this. There is a small / medium-sized high tech project running in your organization. Let’s say it’s an average of ten people for six months. In other words it’s five person-years. While costs vary considerably, the typical cost of such a project in Western Europe or the U.S. might be in the range $ 12,000 – $ 15,000 per day.

I think you’ll agree that such projects fail all the time. And bigger ones and smaller ones. And, if not fail, then run late or over budget (sometimes dramatically so.)

Now imagine that, instead of the project costing say, $ 12,000 per day it was costing ten times that. Or twenty times. Or fifty times. Would you behave any differently than you do?

Well, why don’t we look at an industry where projects do cost ten or twenty of fifty times that per day and see what we can learn?

The movie industry is one where very expensive projects are planned and executed. While there have been famous examples of movies that have gone spectacularly over-budget (Cleopatra, Ryan’s Daughter, Heaven’s Gate, Waterworld) these days, movies get shot with a precision that would keep any CPA happy.

A couple of years ago, I heard an interview with Phyllida Lloyd, the woman who directed the movie, Mama Mia. In the course of the interview she happened to say, ‘It was a seventy nine day shoot’. Now, when’s the last time you heard one of your project managers say, ‘It was a seventy nine day project’? The language used is interesting because you get the impression that if you asked the makers of Mama Mia what they did on day forty two, for example, they could tell you. And they could tell you. Because long before they began shooting the movie, somebody figured it out. Contrast that with our kinds of projects where we’re often slapping our forehead and saying, ‘How could it be Friday already and where did the week go?’

Filmmakers are completely focused on (a) spending each day wisely and (b) keeping the number of days as short as possible. There’s a very simple reason for this. It’s because shooting movies is so expensive. Filmmakers care because of the huge expense that any little delay or wasted time can involve.

So they spend their days wisely. The most obvious way we can see this is when we look at the way filmmakers plan their projects. Filmmakers build what is known as a shooting schedule. You can think of a shooting schedule as being like a giant spreadsheet. In the rows of the spreadsheet are the days of the shoot. The first series of columns contain a column for every member of the cast from the major stars down to the smallest bit part actor. Essentially, an ‘x’ in a cell means that we need that particular actor on that particular day.

After the cast, there are another series of columns for all the other things that might be needed – props, special effects, animals, vehicles and so on. Then each cell contains exactly what we need on that day under that heading.

In essence – they plan at the day level of detail. They view each day as being precious and irreplaceable. Once gone, that day will never come round again. Contrast that with our kinds of projects. We build a not particularly well-estimated Gantt Chart using something like Microsoft Project and then hurry on to start doing the fun stuff – the real work. Often, the best that can be said about such plans is that they are optimistic hopes for the future. We look at them wistfully and say, ‘Wouldn’t it be great if it turned out like that?’

Filmmakers care about their days. We don’t care enough.

So if you work in an industry where time means money, where every day the project runs early is money in the bank, then plan it at the day level of detail. Care about what happens to your days. Spend them wisely. They are irreplaceable.