Geek | Manager

I’m pleased to announce that one of my own projects has just come to fruition. My new book, The Principles of Project Management has just been published by SitePoint. It’s a short book aimed at folks like myself who have come from a technical background and are increasingly finding themselves in need of project management skills — whether to officially take that role or to help make the hard work they put in as developers or designers actually mean something, by ensuring the project is delivered properly.

The book was expert reviewed by Kevin Lawver and Drew McLellan who both did an admirable job of ensuring that the content stayed applicable to all sorts of projects and teams, both big and small. They also bravely took on the role of managementese-weeding and survived with remarkably few lasting scars Drew has written some thoughts on the book on his own blog. I thoroughly enjoyed working with both Drew & Kevin, as well as the team at SitePoint.

If your interest is piqued, then check out The Principles of Project Management book page or download a sample chapter.

In the interests of full disclosure, I would highlight that all the links are affiliate links — i.e. if you buy the book via that link I will both be able to track it and get something back

Bookmark to:

I’ve just invented a new acronym (yeah, yeah, I know, like the world NEEDED another acronym, right?!): DFPS (Deadline First, Plan Second).

Deadline First, Plan Second describes the all-too-common phenomenon of project deadlines being set before any of the planning and estimating has been done. We’ve all been involved in or heard of such a project — the kind precipitated by a big announcement that The Next Big Thing (TM) will be delivered by March 1. Post announcement, a team is pulled together tasked with actually making it happen.

This throws many good project management practices straight out the window. It doesn’t matter if you do a proper plan, involve the team in estimating and figure out that the project will REALLY take 9 months instead of 5. The announcement has already been made — pointing out that it’s unrealistic is only going to get you accused of not being a team player. Alternatively, your management may view it as a crafty way of getting more money or people. So you may go in trying to convince them that it’s not going to happen and come out with twice the money, but you’re still signed up to an impossible deadline.

The good news? People who pull deadlines out of the air often don’t really understand the intricacies and complexities of your project. Duh, right? If they understood, they wouldn’t be setting impossible deadlines! Although this may sound like I’m just hammering home bad news, there is a flip side to this coin. If the deadlines are arbitrarily set, they are quite unlikely to have a detailed understanding of the scope of the project.

Reality is that you can probably negotiate your way through on all the other project variables - cost, quality & scope - you just need to accept that someone high up has nailed their future to a deadline and so now that is set in stone. So long as there’s a big “we did it” announcement on March 1, the definition of “it” is probably fairly fluid.

My advice? If you blatantly need more money or people, go the “it’s impossible” route at first. Get some extra resource thrown at you. Then, very helpfully, start preparing plans of what actually IS achievable for a Mar 1 go-live. Aim low at first — your project board or management team are going to be horrified at how little you’re saying can be done, so they’ll want to argue you up to more stuff. But be very aware of where your limits lie. Plan to under-promise and over-deliver. Give them something that works, but doesn’t sing, dance & play the ukulele. By then they may well realise they don’t need all the singing and dancing anyway!

PS If you’ve been keen to find a way to introduce a new approach, like Scrum then a DFPS situation might be just the leverage you need. Worth a try!

Bookmark to:

I imagine that most of you have aleady heard of Test Driven Development (TDD) where the tests that software should pass are written BEFORE the software itself is written. The list of tests is essentially just a formalised way of listing success criteria (and indeed requirements) very precisely. More than precision, this approach gives you a very fast indication of your REAL progress, since the newly written code either passes or fails the tests*.

Test Driven Development is a software development approach usually associated with agile development methods such as those championed by the Agile Alliance. It is usually assumed that agile development requires a team to be collocated, working intensively and exclusively together, and so little attention has been paid to the role of these methods in outsourced development.

For better or for worse** however, many of us are on one side or the other of an outsourcing arrangement. I discovered in my work that using test driven development as a mechanism for both validation (are we building the right thing?) and verification (is it working?) can be hugely powerful.

There are a number of reasons for this:

1. Well-written tests can explain requirements much more efficiently than traditional requirements documents. Even when there are misunderstandings, the SUM of the different tests specifies the right functionality.
2. Tests are technical and so can overcome communication barriers with added precision. Even just not sitting next to your developers (or designers) can cause communication issues. When you add the moder-day reality of offshoring as well as outsourcing, this can be exacerbated.
3. “The customer” (whoever they might be) can be involved in the creation of the test suite. This helps to ensure that the right functionality is being created in the first place since we can check that what the software does is what the customer desired/expected very easily.
4. Showing the number of tests passed can be a much better indication of progress than the traditional “percentage of task complete” measure. You know exactly how much of the programme actually works at any given time.
5. Tests can be automated. Then you essentially end up with an automatic checklist of desired behaviour, so that every time a change is made you can pinpoint other areas of the code that might have been affected and refactor quickly, rather than waiting for bug reports to come in from live use.

Hopefully as agile development methods become better and more widely adopted, an increased number of the firms providing outsourced development services will start to use them as standard. In the meantime, it can make a huge difference to your projects if you manage to introduce them ahead of the curve.

What have your experiences been with test driven development and outsourcing? Share in the comments.

* Provided your tests are well written, that is. Of course, writing good test cases is a skill all of its own!

** The pros and cons of outsourcing your development definitely deserves another post! Or arguably an entire book!

Bookmark to:

As some might have suspected from the lack of updates here recently, I’ve been rather busy! In the last 5 months I have only been at my office for about 4-6 weeks, spending the remainder of the time travelling in the US, Hong Kong, Philippines and Australia for business and the last month at home in South Africa on holiday.

As a result, I thought I’d break away from productivity and management to talk about travelling for a little while. In future posts I’ll also discuss some strategies for working effectively in teams that are spread across the world!

Without further ado, here’s my common sense list of tips for making international business travel as easy as possible:

1. Reserve your seats and check in online. SeatGuru is very useful for finding the best (and worst) seats — remember to search for the specific airline as well as the plane model as some airlines have very different plane configurations. Also use online check-in whenever you can. Sometimes it can mean the difference between making the flight and not and certainly helps to make travelling a little less stressful. Even good to do when you can’t print your boarding pass — picking it up at the airport is usually pretty painless.
2. Buy a compact, any-to-any power adapter. I have one of these but there’s also a version with USB. It’s been hugely better than carrying a random assortment around!
3. Print out details of your flights and hotels. Carry a folder with details of everywhere you’re staying and all your flights in and out. It’s surprising how important the minor details can be to some immigration officials!
4. Set your watch to the timezone you’re going TO. Getting a headstart on adjusting to the timezone you’re travelling to can mean the difference between a hellish first day and a productive set of meetings.
5. Invest in noise-cancelling headphones if you can afford to splurge. These make a huge amount of difference, but are on the pricey side. I personally missed the boat on these — should have bought them ages ago and then they’d have paid for themselves!
6. Sign up for all the loyalty programmes. Hotels, airlines, everything. Also work out early which airlines are in alliances with each other. It’s often best to just join the loyalty programme of the airline you use most and use that card to collect for every flight in the alliance. This saves you having to deal with the admin of combining your miles/points later when you want to use them. Also, getting even to the first level of membership (whether it be bronze, silver, whatever) can have serious benefits — I’ve been surprised at how often I’ve been upgraded even as a relatively new member of the various loyalty programmes. Any excuse, presumably!

What are your tips for hassle-free travel? Share in the comments!

UPDATE (21 Oct 07) As Tim Beadle reminded me in the comments, Dopplr is a great tool to use when you travel frequently, both as a reminder to visit friends and colleagues in the cities you are going to and also to help you run into fellow travellers who happen to be in the right place at the right time! For the Dopplrites amongst you, you can add me and maybe we will meet up one day. For those seeking an invite, leave a comment and I’ll get you one

Bookmark to:

My first SitePoint article has just been published — Effective Project Management for Web Geeks. For those of you who found this blog because you saw me speaking about Project Management somewhere, it may well sound quite familiar, but I think it’s a nice round-up of some PM basics and the basic toolkit that I recommend everyone get familiar with if they want to keep their projects under control.

Go on over and check it out and let me know what you think!

Bookmark to:

One of the things that becomes a problem as your company (or product or service) expands is how to ensure a consistent experience across the board. Whether it’s that you’re operating in multiple countries or just spread across multiple servers, quality of experience can start to vary, not just for your customers but also for your employees.

This is why in huge companies, “procedure” can come to dominate. You want to make sure that all your employees get equal access to career progression, training, personal development. So you mandate that all your people managers follow certain procedures — annual reviews, work plans, etc etc. You want to make sure that anyone who calls customer service receives pleasant, friendly and above all useful service. In an attempt to standardise quality, you give people scripts, mandate that phones must be answered within a certain number of rings, and so on.

Many of us have felt the impact of these kind of procedures — the call centre guy who can’t wait to get you off the phone, because a “successful” call must be finished in less than 3 minutes; the manager who sits you down for a stale, scripted “career discussion” that makes you feel more like leaving the company than going for that next job or promotion.

My theory? These procedures are written in with the best will in the world. The need to write them down is the problem however — the “spirit” gets lost. People become slaves to the letter of the rules.

Have you seen this happen? Ever seen it combated in an effective way?

Bookmark to:

The most frequent mistake I see in Project Planning is what I call “premature Gantting” — going straight to creating a huge Gantt chart (often in MS Project).

Why is this a mistake? Because a huge Gantt chart, with many lines of tasks, all precisely allocated to specific dates looks very authoritative. It gives the impression that you’ve spent hours working out the exact dependencies, estimating the length of tasks and precisely scheduling all the work that needs to be done and who needs to do it.

If you truly have done all that work, then perhaps you’re fine. But the reality is that most of us have ACTUALLY spent half an hour scribbling on the back of an envelope, or at best on a flip-chart, to get some rough stages and some key dates. All the detail was then made up when the Gantt chart was created, primarily because the software demanded it.

What’s the solution? Let the format of your plan reflect the stage of development that it is at. Internally, I will frequently go into a meeting and DRAW the plan stages on the whiteboard. For communication with the customers/stakeholders, I’ll create a simple plan (sometimes even a flowchart) that reflects the reality of the situation.

So far, everyone involved has appreciated the honesty — and it’s prevented projects going wrong at a very early stage in the game.

Bookmark to:

Every time I do a talk about project management, someone asks me what the “right” software is for the job. I love being asked this, because it’s an important topic.

My honest belief is that tools don’t matter.

Project management is about people. Picking some all-singing, all-dancing piece of software is not going to make things magically go right. It’s only when your processes are already working that the right software can help you make things run more smoothly and efficiently.

Net, focus first on getting the processes right. Then worry about selecting the best software for the job.

Keep in mind, however, that adoption is of supreme importance when selecting tools for project management. At the end of the day, you may need to compromise on features for the sake of pragmatism. It doesn’t help anyone if you have a fabulous project plan that no one can read, or an issue list that no one will update!

Bookmark to:

I’ve just done my talk on Geek Project Management at today’s Refresh Edinburgh event. It seemed to be fairly well received (fingers crossed anyway!). Some of the content was pretty similar to my BarCampLondon2 presentation, but I’ve done a fairly significant rework on it so I think it’ll be a lot easier to take away some immediately useful tools.

If you’re interested in seeing the slides, then here you can find them in Powerpoint and PDF form.

Tags: refresh edinburgh, refresh, edinburgh, speaking, project management, management, geekmanager.

Bookmark to:

One of the most interesting concepts I came across when I was just starting out in my corporate career was the PIE model - Performance, Image, Exposure. Typically this is represented by a pyramid diagram or a pie chart, depending on how pun-driven the explainer’s sense of humour is.

In terms of an individual’s career, the 3 segments represent the following:

• Performance: The actual work you do, the results you deliver.
• Image: The impression that others have of you (obviously this can differ from person to person).
• Exposure: The people who get to know about a) your results and b) your image.

At first, it was a concept that really didn’t sit well with me. It didn’t seem FAIR. Surely one’s career should really just depend on the results that you deliver? If you’re good at your job, you should do well, right?

If I’m honest, that feeling stayed for quite a long while. I resisted the concept that you needed to care about your image, about your exposure. I believed that I could just do my job and that the results I delivered would be what mattered. I wouldn’t need to care about image or about getting known by the decision-makers.

All that changed because I was asked to write some feedback for someone. The person in question was someone I actually hadn’t worked with as directly as others for whom I had written performance evaluations in the past. I realised that since I hadn’t been working directly with them, I didn’t really KNOW about their real work and their real results. Strangely, though, I still had definite opinions, both of what they were doing well and what they could improve on.

This is what made me realise that image and exposure are both important — and factors that you should ignore at your peril.

Whether you like it or not, only a limited number of people will get to work with you directly. Even those that do will get a fairly narrow view of the real results that you deliver. On the other hand, many many more people will form an image in their minds of what you’re like — perhaps that you’re a safe pair of hands, maybe that you’re very smart or very ambitious. Some may form a very negative image — that you’re a bullshitter or unreliable or untrustworthy. The combination of that image that people have of you (Image) and the groups of people that share that view of you (Exposure) can make or break your career.

The big light bulb moment for me was when I accepted that Image and Exposure were going to matter whether I cared about them or not. Of course Performance is also important and always will be — I firmly believe that folks who try to make it all about the image and the exposure are playing a dangerous game of smoke and mirrors and will eventually be caught out. But the difference between two colleagues with comparative performance, one of whom cultivates the type of image they want and makes an effort to get the right exposure and the other who ignores these facets completely … well, it can be very significant.

Bookmark to:

The people I really respect are those who can get mountains of work done and deliver amazing results … and still have a life.

It’s really easy to mistake “busyness” for productivity. The folks always rushing around, having meetings and complaining about how busy they are certainly LOOK like they’re doing a lot. But the reality is that effort and output are not always related. Productivity is about getting loads done — how you spend your time should be up to you.

Some busy people are also productive; some productive people are also busy. There are times when you’ll see me running around like a maniac, juggling half a dozen projects and priorities. But if you measure (and therefore reward) “busyness” as opposed to results, then you won’t get what you want. You’ll get an army of employees who are too busy to talk to each other and potentially on the verge of nervous breakdowns, who actually don’t achieve very much.

Measure results. Measure the outcomes, not the actions. Don’t reward someone for working night-and-day on a task, reward them for producing the deliverable at the end. Reward the person who gets the same work done in less time MORE than the person who is missioning for days and days. That way, you’ll encourage your team to be more productive, rather than just busier. They’ll find their own ways to improve the way they work and the entire team will benefit as a result.

Bookmark to:

A recent article about refactoring your career made me think back to when I first read “Rich Dad, Poor Dad”. For those who haven’t read it, “Rich Dad, Poor Dad” is a personal finance book — some of the advice is a bit variable (e.g. he recommends against diversifying your investments, which I 100% disagree with), but there are some good concepts in there.

One that struck me at the time as making a lot of sense was the thought that you should always pay yourself first. In the financial world, this means contributing to your savings and investments and pensions and so on BEFORE you pay your bills or buy any “extras”. This disciplines you into saving/investing regularly.

The same is true in terms of your career. You NEED to invest in your own training and development first, in order to have a dynamic and rewarding career. Concepts like Google’s 70-20-10 rule are similar to this — you need to not only focus on what is making you money now, but also what will make you money tomorrow and next year.

In terms of your career, this means that you should be setting aside time for training and development — some of which is focused on making you better at your current job and some of which is focused on getting you towards the next step in your career … and some of which should move you towards your long term goals.

How do you include training & personal development into your life? Do you find it hard to find time to invest in yourself? Share in the comments.

Bookmark to:

Parkinson’s Law says that “work expands to fill the time available”. If you don’t have much to do, it doesn’t inspire productivity. If you have loads to do, it often inspires procrastination, but I digress.

Today, however, I want to address the corollary to this. Some people seem to believe that since work expands to fill available time, work will also CONTRACT to fit the available time. It usually plays out like this:

Project Team Member: Getting the environment set up took two weeks longer than anticipated, so now we don’t have enough time to test. I think we need to move the go-live date.
Project Manager: No, no, I’m sure you’ll manage it.
Project Team Member: As I said, I think compressing the testing down to just 2 days is a serious mistake. We’d be risking the whole project!
Project Manager: Listen, I’m sure you understand this is a really important project. We MUST make that date. You’ll just have to make it work.

This, my friends, is Management By Optimism. It is probably the most dangerous management trend in evidence today. When you see it, start to worry, because it is probably the biggest threat to your projects and to your careers.

Management BY Optimism is very different to being optimistic. Being optimistic is seeing the cup as half-full — trying to think the best rather than the worst in a given situation. Management By Optimism, on the other hand, is about IGNORING potential failure. Just because the impact of a particular risk is severe, the risk is regarded as extremely unlikely. Rather than facing the problem and dealing with it, it is ignored until a catastrophic point is reached — or until the relevant manager can jump ship and blame the sinking on the crew.

So what can you do if you worry that Management By Optimism will scupper your project? Well, firstly, look out for the signs. Failing to consider real risks, reacting adversely to the suggestion that the plan or schedule is unrealistic are both big warning signs. Secondly, try to address the problem in a constructive way. Sometimes we all delude ourselves into thinking things are better than they are. Holding a team risk-assessment meeting can help — just get everyone to rate how severe and how likely they think a risk is. It will quickly become apparent if the team cannot envision a successful outcome when the leader is dead-set upon it (and vice versa).

Or, if there is no other option, bring in the big guns — take it as an issue to the Project Board and make clear that there are real concerns about the chances of success. Much as “it’s going to be late/over budget/under quality” is unlikely to be POPULAR news, any senior manager worth their paycheck should realise that early warning is significantly better than unanticipated failure.

Do you have some examples of Management By Optimism and perhaps other ways to combat it? Share in the comments!

Bookmark to:

Solving problems isn’t hard. Once you know what you’re trying to achieve, then for most problems you can see a few ways to get there, so it just comes down to choosing the best course of action and following through.

Problem definition, on the other hand, can be damn hard.

When you’re facing some problem and it’s driving you crazy, sometimes you’re best to stop and wonder whether you’ve really defined the problem accurately. What are you trying to solve? What is the original problem? Why is it such a problem? How else could you frame it? What description would make it more tractable?

If you can get the problem definition right, your chances of finding an optimal solution are greatly improved. Don’t keep soldiering on down the wrong path, refusing to acknowledge that failure is also an option.

Bookmark to:

Ever get a great idea and then forget it because you didn’t have a pad and paper to hand? Ever wake up in the middle of the night with the solution to your biggest problem and then in the morning have nothing left other than that nagging feeling that you’ve forgotten something?

This used to happen to me all the time. First, I tried carrying a hipster PDA, but remembering to take it EVERYWHERE was difficult. Then I realised that I already had something that I always carried with me — my mobile phone!

Now, I have a very simple process: any time I get a good idea, whether it be for a blog post, a solution for a wicked problem or an idea for a great new site, I send myself a text. Try it — it works great!

Bookmark to:

This blog is hosted on the normally excellent Dreamhost, who unfortunately today had a planned power outage that ended in extra hinkyness. Everything should be back now — apologies to anyone who was trying to get through to read or post comments during the downtime.

Bookmark to:

Although I won’t do a full repeat of my talk at BarCampLondon2, today I wanted to talk a little bit about starting out in Project Management. Most folks don’t start their career as a project manager … they come to it later, having been in an operational role or part of a project team first.

One of the difficulties for a first-time project manager is that being a great project resource (i.e. team member) is what gets you the job as project manager, nine times out of ten. Unfortunately, the characteristics of a great project resource are not necessarily the same as those of a great project manager. Standing out in a project team is about getting more done than your fellow team-mates, knuckling down and “getting on with it”. By definition, this focuses you on the executional level of the project — getting tasks done, once they’ve been assigned to you.

In contrast, being a great project manager requires excellence at all the OTHER parts of the project — planning, communication, dealing with stakeholders, managing risk, seeing the “big picture” and so on. There’s also a big part of project management which is more about management than about the project — your team will function best if they are left in peace to do their work and move the project forward, so making sure they don’t NEED to worry about all those factors is paramount.

In traditional project management, there are a number of stages: Initiation, Planning, Execution, Control and Closure. The crux of my talk last weekend was that the real success or failure of a project is determined in the Initiation, Planning and Closure stages, whereas most of the focus is traditionally on the Execution & Control phases. This is not to say that these are the most time-consuming phases — nor that the Execution & Control are not important! — just that they are the structure that allows for success .. or not.

In my experience, some of the most typical mistakes first-time project managers make are in these stages:

• INITIATION — not making sure everyone is 100% clear and aligned on the purpose of the project. Realising this later on when the software “doesn’t do what we wanted it to do” or when the savings/value promised are not delivered is much more costly.
• PLANNING — thinking that the plan, once written down (as thousands of lines in MS Project) will be followed to the letter. Plans are not robust. Task planning is especially fragile. If you spend your time worrying about the fact that task #137 is only 70% complete, then you’re not keeping your