Deadline First, Plan Second

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!

Outsourcing and Test Driven Development

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!