The New Frontier

I recently fell off the face of the Earth for a while having something called a 'child' so apologies for the lack of update, but fret not. I have plenty to fill you in on!

If only the me of five years ago could see the monster I have turned into today. The old me was in the midst of quite a large development, for which I was the sole developer, and was becoming increasingly frustrated that I was being managed by multiple project managers. Bring it back to today and I am lucky that I now have a team of developers, but can't shake the niggling realisation that I have become more and more detached from the code, and more like a project manager!

Thankfully if that person from years back was working for me I would like to think that they would be happy in the environment I hope I have created. Where interactions with nodo's, none dooers, is at a bare minimum and my approach to project management is becoming more realistic everyday, rather than the opposite. There have been plenty of mistakes, I have even put the team in a similar position to the one I was frustrated by, but we evolving rapidly and growing in confidence. Here are our biggest lessons, which I wish I could send back to my younger self:

Get The Right Spec

I am sure a lot of you are screaming that this is beyond obvious, but even though we had a spec at the start it had holes, and these led to major headaches which we still feel occasionally today.

Most crucially, give yourself time and allow lots of iterations on the documentation and mock designs.

(Complexity/Time spent specifying)^2 = time required to deliver

Ignore Optimism

Our team is fortunate as our stakeholders are part of the business we we work for, so it's not likely that if we give an unsatisfactory timescale that our stakeholders will approach other vendors. Honesty about a project's timescales is vital, and approaching your estimation as an optimist can sway you into dishonesty forcing you into setting unachiveable goals. Something that can multiply this is knowing your stakeholders business, and the timescales that are unique to their trade. This was an issue for us as we work for an academic publisher so our goal was guided by our desire to release over their summer break. This made us estimate to fit the business goal, which just doesn't wash with software engineering.

Leave Your Fat Alone

When presenting our project plan we set it up to be so lean, with next to zero contingency see previous section Ignoring Optimism. I guess in hindsight it was to appease our stakeholders, which is no bad thing, but a short term shock at that point would have avoided the long term pain that such a lean plan resigns you to. If I were to redo it today I would leave a significant amount of contingency, at least a quarter of the total development time and probably twice the big fixing time, in the presented plan. This would have pushed us past what we knew the business goal was, but we should have given the stakeholders that choice. If the stakeholders had cut the fat they would have assumed some amount of responsibility and would have shared our fear of living on an optimistic dream! Which burst...

Reevaluate Away

One thing that I think our team has got quite good at is reevaluating a project plan, and coming up with quite creative ways to get somewhere back to being on target. The thing with these sessions is that they are quite painful, as you have to admit that your goal is unachiveable. What I have found is its vital to have these sessions in a fresh environment, preferably away from your day to day office. It's also best to go as digital free as you can, take big bits of paper, print outs of any remaining project tickets/schedules/plans and at most have an iPad for when you need to know something.

Get Tooled

As part of a bigger organisation that really does little in the way of software engineering, our team struggles to fit within the internal IT mould. So we have always struggled to get hardware or software that can go through the bigger enterprise machine and to us before it has become grossly out of date. As a lead you can't let this stop your team, it is vital that they have the equipment and tools that they want. Each of them will have their quirks and will be familiar with a certain way of doing things that'll ensure they go as smoothly as their skills will allow. A few key pointers:

Go Agile

I should probably reiterate, I am not a project manager, but I advocate agile project management very highly. As someone who has operated on the receiving end of countless Gantt charts, and someone who has acted as a product owner, it's simply the only way to go. A few tips:

Maintain The Funs

This is super important, my experience is that developers can be some of the most creative people out there and they need a certain amount of space. Even if it's just a few hours on a Friday afternoon you really need to take some time out to do something different. Keep it light, and definitely within a stones throw of your actual discipline, but it has to be something that excites them. We make games, reimplement our content for bizarre devices or channels, or make apps that try to predict the World Cup scores!

It would be my hope that if the me of five years ago joined my team today he would be happy in his work. He would feel excited, challenged, valued and have the right materials to do the job that he is wants to do.

comments powered by Disqus