It’s not a sprint…

Yesterday I ran the longest distance I’ve ever run (31.5 km or 19.5 miles), and for the longest time I’ve ever run (nearly 4 hours). It wasn’t fast, but I was very happy to complete three quarters of a marathon at a consistent pace. It was certainly a lot harder maintaining that pace at the end, but it does show the importance of not blowing all my energy in the first 10 miles.

The training plans tell me that I’ve now run as long a distance as I need to in training for a marathon, and I certainly feel happier now that if all goes well I do have a hope of finishing – something that didn’t seem so likely just a week ago when I struggled to finish 17 miles. However, the other thing the books say is that the last 6 miles are as hard as the previous 20, so no smug feelings yet. It’s rather tempting to try a run over the full marathon distance just to see what happens. If I made it comfortably (I use the word in relative terms here) it would do wonders for the confidence, but everyone says don’t do it. There’s a risk of breaking myself, and of course it would be very bad for the morale if I wasn’t able to go the distance.

I did the run as 3 laps of a 10.5 km route from home (so 4 laps would be a full marathon), which gave me a chance to pick up water – I find it a nuisance to carry more than half a litre, and that’s not enough for 4 hours of running, even in these relatively cool conditions. In practice I only did one water stop, after the first lap, so I survived on a litre, which is probably less than recommended. The first half litre was just water, the second contained an energy supplement. I didn’t feel particularly thirsty while running, but was certainly pretty dehydrated after I finished.

Learning points?

  • The run was a successful implementation of good pacing. The intention was to run at around marathon pace, and I was able to maintain that pace consistently and feel that I could have gone further
  • My feeding and drinking worked fine for that distance, but I think could have been a problem with another 80 minutes or so of running. It would be good to see the effect of another drinks stop

You were a project manager, right…

These were the words just a couple of days ago in a Facebook chat with someone I met in the twilight of my career. She wanted to catch up with me to talk about project management – a nice thought, but what have I got to say?

I got to thinking. I spent most of my career doing project management or something very close to it. Even in the last few years when I was supposedly into business development and marketing, a lot of my work was informed by project management experience. It’s a lot easier to sell a project development if you can talk intelligently to the customer about what’s involved. Trouble is, like many areas of expertise, if you know what you’re doing project management seems obvious – until you see how badly some people do it. In this blog I’m simply going to skate over the surface, stating the obvious – I don’t think anyone would want to stick around for the full treatment, and I’m certainly not going to get into a philosophical discussion about waterfall or agile methodologies.

Project delivery happens in phases – some of these can overlap, sometimes they become iterative, but delivery of a project is about moving from nothing but an idea to a set of tangible deliverables. Often when projects go wrong it’s because people forget about some of the phases, and even more commonly they work with a silo mentality, limiting communication across departments and disciplines, which can lead to less than ideal project outcomes.

Concept phase

Someone has an idea which might become a project. But what is it? In this phase we are talking about the “what” and the “why” and emphatically not the “how”. Techies will want to discuss the “how” at the earliest opportunity, and often either forget about the “what” and the “why”, or think they know better than the customer/user/stakeholder. This phase is about defining the requirements. To do it properly we need to work closely with the customer, users and stakeholders, as well as the breadth of company activities such as sales, marketing, finance, customer support and training.

  • Deliverables – agreement of all parties on the deliverables is crucial. If we don’t know what we’re delivering, how do we know when we’re finished?
    What is actually wanted?
    What will it do and why?
    What are the benefits?

    Can we identify customers, users and stakeholders and do they agree on the objectives?
  • Budget – in most environments a project must make financial sense.
    What budget do we have for delivering the project?
    How much is it worth spending?
  • Timescales – a project is usually only valid in a particular timeframe.
    When is it needed?
    When would it be too late?
    Is it possible to be too early?

Planning phase

Once we have a handle on the requirements, we can start thinking about “how” we will deliver. Typically we will discover things in this phase that cause us to go back and consider the requirements. It’s fine to go back and revisit the previous phase, but make sure you don’t get confused between the “what” and the “how”. We still need to be working across the many departments of the organisations involved – very often the technical teams will think that they own this phase. They should not!

  • Resourcing – we need to determine who will be involved in delivering the project, and where will the money come from.
    Who is in the project team?
    Do we need external resources?
  • Cost – this is deeply dependent on all of the other parameters in this phase. It’s pretty important that the development cost is in line with the budget identified in the previous phase. I have worked on many projects which would not have happened if we’d known the true costs when we’d started. There can be ways around this, such as finding other revenue streams based on the development (maybe technology licensing, for instance).
    What will it really cost?
    Who pays if we’ve got it wrong?
  • Technology – we need to consider the technology we will use for this project, both in terms of the underlying deliverable and the tools used to develop it.
    What technologies could we use as the basis of the project deliverables?
    What about development tools?
    Do we have experience is these technologies?
    Do we need external resources?
  • Timescales – this is a different question from that in the previous phase. Then it was “when do we need it?”. Now we’re asking “when can you have it?”
    How long will it take to create the deliverables? Even if we could estimate perfectly (and we can’t) there is no single answer to this question. The deliverables might come in parts over a period of time, or be delivered in a number of different ways. It might be possible to deliver earlier if we were to spend more money.
    How long will it really take? Think about risk. You need to be realistic about the timescales and factor in some contingency. If the project is very similar to 10 you have repeatably done before then the contingency can be small. If it’s based on brand-new technology that no-one has ever used, it will probably take twice as long as you think, even when you have factored in some contingency.
  • Methodology – in the good old days we (in theory) carefully defined a project specification in minute detail before we started the development process. It is fashionable nowadays to use agile development, which takes account of the fact that we don’t know everything we need to know before we start. Each methodology has its advantages – and its disadvantages.

Execution phase

On a technical project, this is what the developers regard as the real work. They start coding and developing the electronics. But in the real world we also need to take into account the needs of the marketing department, sales, customer support, and test teams. Many immature companies regard these as serial activities rather than taking a holistic team approach.

  • Progress tracking – the methodology zealots will talk of stand-up daily meetings for agile developments, or meticulous tracking of hours spent and earned value for more traditionally run projects. This is what some people regard as the core of project management.
    Are timescales on track? It’s an easy question to ask, but devilishly difficult to answer. It’s often the case that projects stay on track until the 80% point, and then take as long to finish as they took to get to that point.
    Are costs on track? This one is probably even more difficult to answer
  • Customer management – also taking account of users and stakeholders.
    Is progress what we expected? We need to be setting appropriate expectations.
    Have we met unforeseen technical obstacles where the customer could help? Sometimes we can struggle expensively to solve a technical problem, when talking to the customer would have established that it’s not important.
    Are there potential follow-on projects? We might have decided to postpone solving a problem until later, or have identified an opportunity for further development. We need to start talking as soon as possible.
  • Scope – almost certainly the customer will realise at some stage that the original requirements were not correct. That’s fine, but we need to realise that the later we make that discovery the more it will cost. Moving goalposts cost a lot of money – but there’s no point in delivering something which is no longer appropriate.
    Is this a real requirement, or just a nice-to-have?
    Is the whole of the customer organisation in agreement?
    Has the customer analysed the benefits?
    Have we analysed the full cost and timescale impact?

Handover phase

We’ve finished the project, so we hand it over to the customer and (if it’s that sort of project) get paid. Simple! Ideally handover is an event, not a phase. But in reality, not everyone agrees that it’s finished, and it’s probably not on time. If we’ve been doing it right the other departments will have been marching with us during execution, now they come to the fore. Sales, marketing, training and customer support all need in their own way to get hold of the deliverables and work their magic.
Do we have agreed actions, timescales and payment schedules to tie up the loose ends?
Can we make sure the developers don’t disappear to more exciting projects before they’ve finished the job? 
Have we scheduled a cross-functional project review (including the customer where appropriate) to analyse and learn from this project? 
Have we kicked off the process to secure follow-on work before we lose the team expertise?
Have we put in place appropriate warranty and support processes, taking into account the probable change of timescales since they were initially agreed?

Post delivery support phase

This is both an opportunity and a problem. The customer, users and stakeholders will probably want the deliverables to function for many years. But the project development team will be working on new and exciting projects. An existing (and happy) customer is a valuable asset for up-selling and cross-selling.
Are we staying in touch with the customer to ensure they’re happy?
Are we looking at opportunities to upgrade the original deliverable, or move it on in relation to today’s technology? 
Do we have a succession plan to ensure that developers have an interesting and challenging career path, but we maintain the ability to support legacy products?

Further reading

No-one agrees how many phases there are, or what activities take place, but here’s another view:

https://www.smartsheet.com/blog/demystifying-5-phases-project-management

Back on track?

Near the end of the 2018 Colchester Half Marathon

After my bad back panic of last week I did no training until Saturday – a whole six days without a run. The run on Saturday was a purposely warm and gentle 30 minutes on the treadmill. Pleasingly I didn’t feel my back at all, so my problem, whatever it was, had gone away as rapidly as it came.

So how to get back into a training routine? Since my treadmill running had been fine, I concluded that the week off would be the equivalent of a taper before an event, so why not go for a long run? So yesterday I set off at what I thought was a suitably gentle pace for my now regular 27km long run. I was having to guess at the pace, because the strap on my Fitbit had broken (as it does once a year).

My legs were feeling much less fatigued than they had in my recent weeks of intensive training, my back was comfortable, and at around five miles or so I was feeling good. There was even a bit of sunshine.

I always find the last 3 or 4 miles (the bit after I’ve done half marathon distance) of the my long run pretty tough, physically and particularly mentally, but this was something else. I was able to keep jogging, just about, one foot in front of the other, but it sure wasn’t pretty.

I’m still not sure what was going on –

  • had I gone too fast at the start?
  • was I still suffering from the after-effects of my cold?
  • did a week without running really have that much effect on my endurance?

Lots of questions and no real answers. I’m hoping that at I have at least gained something useful by experiencing those few miles of very tired running – could be useful in London.

Why wasn’t I surprised?

The only slightly surprising thing about this story was that it made the news at all – and that is surprising partly because it’s hardly news that bullying goes on in the workplace (from Philip Green downwards, or perhaps that should be upwards), and partly because those affected rarely go public either through fear of career repercussions, or because they think it will make them appear inadequate. It’s been reassuring to see a mostly positive response to Olivia Bland’s story.

After a career of more than 40 years in the tech industry I know that despite its young, hip and cosy image of pool tables, ping-pong and bean-bags (all true) there is no shortage of bullying behaviour and for many this starts with the interview. While I have certainly been subject to bullying from managers once in a job, I’ve been fortunate and not suffered direct bullying at job interview stage. That’s not to say that I haven’t had my fair share of cocky arrogant people trying to show me how clever they are, but I’ve attended most of those interviews as an experienced professional, and been able to respond appropriately at the time (I can be cocky and arrogant too), and walk away from the job. That’s much more difficult for junior personnel and those desperate for a job.

But I have been a part of organisations where the ritual bullying of interviewees was institutionalised. Techies who spent most of the day wearing earphones, staring at their screens and talking to no-one could be seen stalking around the office with a manic grin rubbing their hands in anticipation of locking a poor victim in a closed meeting room for a couple of hours posing questions designed as much to show how clever they were as to gain any insight on the abilities of the interviewee. It served as a group bonding exercise for the perpetrators, so I guess that helped morale, but I’m sure many good applicants slipped through the net, and the company lost the powerful benefits it could have derived from a more diverse workforce – those who did survive the process tended to be clones of those doing the interview.

See also my earlier blog on workplace bullying once you’ve got the job – Business Bullying – “You’re Fired”: http://www.cliffdive.co.uk/business-bullying-youre-fired/

Marathon Training – a Setback

For the last three months I’ve been consistently running five days a week. Now, with less than four weeks until the Cambridge Half Marathon, training has come to a halt. The last time I ran was Saturday, and it’s now Wednesday. I should have done my long run on Monday, but was unsure about that since I had a cold – no big problem for shorter runs, but probably a bit silly to flog through 17 miles just for the hell of it. But that little debate between my rational pragmatic self, and the obsessive part of me that said “Rules are rules – if you deviate from your training schedule you are doomed” became superseded by a more serious problem. Somehow, fiddling around trying to connect a car battery I strained something in my back, and could scarcely walk. Even the obsessive part of me couldn’t run – and I haven’t run since.

I’m not too worried about the Cambridge Half Marathon. I know I’ve got enough residual fitness to run that distance without much training and anyway, if the worst came to the worst, I’ve already run it a good few times, and I’ve been running more than a half marathon every Monday for the last month or two, so nothing to prove really. But what about the London Marathon at the end of April? My first full marathon, and I was lucky enough to get in through the ballot. My training had been going so well I was beginning to believe it was all possible. But a full marathon is a long way. How much training can I afford to miss? On the other hand, if I try to get back into training too early could I break down entirely?

This is my first training crisis – in fact my first training problem of any kind. It had been going superbly. I should be pleased that it didn’t happen a day before the marathon. As a life-long project manager I should have expected some sort of crisis in the delivery of this project. If I look at my previous experiences, I should be pragmatic. Chances are I’ll recover soon enough to get training again without too much effect on my endurance – maybe.

I’m not keen on what comes out of America, but there’s one quote that’s always worth considering at these times.

“Ain’t no sense worryin’ about the things you got control over, ’cause if you got control over ’em, ain’t no sense worryin’. And ain’t no sense worryin’ about the things you don’t got control over, ’cause if you don’t got control over ’em, ain’t no sense worryin’.”

Mickey Rivers – former player in Major League Baseball from 1970 to 1984 for the California Angels, New York Yankees and Texas Rangers.