Category Archives: Project Management

General, Project Management

What’s your most optimal process?

2 Comments

If I had a business, I would choose to have some of my “overhead” processes optimised such that they cost me the least amount of hassle, downtime and thus money. I would do this because processes that are an overhead to a business can really eat into folks motivation, especially if the amount of red-tape they have to handle gets too much. One such process that I would optimise is the “admin” process. Nobody likes excessive admin, yet in business we find it an increasingly popular activity. The trouble is, too much admin can lead to de-motivation which can then lead to stagnation, something that was covered in today’s Guardian.

De-motivation and stagnation are the two things that you don’t want your key personnel falling foul of. These folks are the first to be heard lamenting about the excessive overhead of admin, using phrases like “we’ve lost sight of where we’re going” and worse like the potentially blasphemous “our head is going up our own backside”. If you hear these phrases, it may well be too late. But if you’re early enough, all is not lost, something can be done! How do you identify “what” can be done? Well, the answer is remarkably simple: just ask your key personnel to list what’s bothering them from an admin perspective. You’ll them have a ready-made list of ways in which you can save money and motivate your team. It’s one of those “win-win” situations.

Key personnel don’t want to spend time “out of process”, where “process” means their job function, i.e. what you pay them to do, their professional service to you. They want to focus on their job, focus on the project and focus on what they can do to make everything easier all round. However, if your business plants landmines of administration in the paths of key personnel, any projects that they are working on will take a serious schedule hit. Key personnel will attempt to side-step the landmines, but eventually they’ll stand on one, and boom, de-motivation and stagnation are the injuries…injuries that are very difficult for the business to recover from (ultimately, the injured personnel find another job).

It’s very important to recognise that admin need not be overwhelming, just enough is enough. Admin activities are overhead, they do not contribute to the bottom line, every admin hour costs you at least two hours of at an hourly rate on a project. Focus on activities that increase your turnover, and anything that can increase your profit: seek out activities that eat into your turnover and profit, optimise or eradicate them.

The old adage of time is money stands true. Don’t thwart the progress of key personnel by making them meander through an administrative minefield.

PM#, Project Management

PM#9 – Avoid duplication of effort

4 Comments

Doing the same job once is optimal.

Doing the same job twice is criminal.

Doing the same job three times is just plain stupid (this happens, I’ve seen it)

Doing the same job four or more times is criminal and plain stupid (this happens too, really, it’s true)

Duplication of effort manifests itself in many ways, a few of which I’ll discuss here:

  1. Procrastination.
    We’re all guilty of this. Put simply, we look at our to-do list and we “hum and haw” about which item(s) we want to work on. Some items are too big, we feel that we’ve not got the time to do the item justice so we put it off. Other items are boring, so we focus in on the more exciting and less tedious items. In reality we should be focusing on the items that will add the most value to the “big picture” or the overall project. If you don’t think you procrastinate, try following the suggestions in the Touch it once topic below.
  2. Two (or more) groups expecting the same information from the same source (often in a slightly different format).
    This is a “duplication of effort smell”. Folks start seeing project-related data that is of some interest to them…they start to ask for reports based around that data without realising that reports actually take time to create, they fail to recognise that the report author has other things of greater importance to the project to work on. Similarly, if the underlying data changes, the report author has considerable round-tripping (going back’n’forth) in order to push the updated information out those who [claim] that they need it.
  3. The wrong people being involved.
    Hi-jacking of information is not uncommon and is one of the “duplication of effort smells”. A project can be making good progress, then all of a sudden, somebody starts taking an interest in parts of the project that really are outside of their skill-base. This is actually similar to 2 above whereby the wrong people sudden get involved by asking for reports/data in a format that suits them. They often join the party late, i.e. they did not realise that the data might have been important to them at the start of the project. If the wrong people are involved, it often manifests itself by virtue of the fact they have arrived on the scene after the scene of crime officer has been and gone, or by virtue of the fact they do not use the report/data correctly (or at all).
  4. Failing to start it…finish it.
    Similar to procrastinating, we often find ourselves revisiting an activity or task thus incurring the “start-up smell” whereby we have to spend time “getting back up to speed”. Interruptions are a key indicator that tasks will be started and returned to at least once prior to completion.

Touch it once
During a discussion about time management, a colleague pointed out a technique that appealed to me. How often do you pick up a document, look at it, procrastinate over it, then put it down again? You’d only be human if you agreed that you frequently pick documents up more than once! My colleague presented a well-known technique that catches this procrastination: each time you touch the document, you mark it with a red dot…the measles inducer. When you reach three red dots, you should agree with yourself that something has to be done with it. More about this common time management technique can be found here.

Of course, touching it more than once is a duplication of effort smell and the red dots will be the give-away…

The perils of the solution…
Obviously solving any duplication of effort requires that the duplication is identified. There are many reliable methods of doing this, not least a basic work-flow analysis. However, identification is the least important part of the solution. Once identified, removing the duplication enters into the realms of a political quagmire. The parties responsible for each part of the duplication will endeavour to prove that their duplicated process is the best one and that one that should be kept. They’ll also argue that their process is required for their day-to-day business, or that it is critical to the project or is just part of the fixtures and fittings (an unwritten policy or procedure if you prefer). This is your biggest problem, convincing those involved in the duplication to change their ways, to accept a single more optimal, more efficient way of achieving the same – a way that costs less, is completed quicker (early access to benefits, etc.) and generally makes the project more friendly and more approachable.

You may also encounter push-back when tackling item 2 above. Folks will cite “systems” as their need for the same data in different formats. “Our XYZ system needs project activities to be recorded in days”…whereas…”our ABC system requires project activities to be records in hours”. An easy conversion between hours and days may be possible, however in reality, different folks work a different number of hours per day. In such situations, where folks are perhaps being blinkered by the proximity of their problem and the need for the data in their format, where folks are unable to think out of the box, we must find a way of allowing them to take a step back from the problem itself. This will allow them to see the bigger picture, to understand the problem in context, to realise that they might need to change their processes in order to provide a better service now and in the future.

Whether you identify those involved in the duplication before or after you streamline the duplication down to a single activity, is up to you. In some instances it might be better to invite “the duplicators” into a [stand-up] meeting that can be used to determine the streamlined activity…this might win you friends and get you more buy-in. Either way, identification and removal of duplicated effort is paramount and should be embraced by all parties.

In this series:
#8 – Multi-tasking is evil
#7 – High workload means lower productivity…
#6 – You were right and I was wrong
#5 – Whose schedule is it anyway?
#4 – Start it…finish it
#3 – Use e-mail properly
#2 – Focus on the project
#1 – decision making

Project Management

Agile in the Financial Times, Summer School, Day 18

I enjoyed my first business trip for August today – Edinburgh to Manchester and back again. And, contrary to some corporate travel policies, I returned home on a business class ticket – how did that happen? Business class afforded me the luxury of access to the BMI lounge at Manchester airport…where I picked up a copy of today’s Financial Times.

The Business Life Summer School series revolved around the subject of “Technology is the secret of an agile advantage”. Naturally, the word “agile” caught my eye.

The article itself was written by Mohan Sawhey, Tribune Professor of Technology and Director, Center for Research in Technology and Innovation, Kellogg School of Management.

It opened with:

“Today’s changeable markets require companies to value flexibility of efficiency and speed over scale”

This is rather reminiscent of the Agile Manifesto. Being responsive to change is the key driver here, if you are able to adapt your business direction, your product or your services such that they match market or customer needs, you will gain a competitive advantage. And how do you do that? Well, as Mohan says, “sense-and-respond” (responding to change over following a plan) organisational models that promote “modularity” can achieve this. In the software world, this is of course, iterative development.

Of course, Mohan’s mention of XML also caught my eye. With XML in the mainstream now, Mohan’s comments serve to firm home the huge benefits that XML gives us today. Yes, it is a really good mechanism for the development of agile IT systems. Mention of decoupling IT systems into layers (presentation and data are mentioned) proved to be a draw too. That said, the information Mohan presented, whilst correct, is a little over-used – sometimes people need to be told and told again before the good stuff sinks in I guess.

Modularity enables agility

Mohan explained that the key to “agile” is modularity [of products and IT systems] and decoupling of business processes and value chains, the latter might be seen to relate to the Agile Manifesto’s “individuals and interactions over processes and tools“. In other words, business processes should be placed far away from the associated value, i.e. don’t throttle the front-end service that adds most of the value by embedding a process overhead into the equation.

Increased modularity allows business processes to be swapped out, or “plug’n’play” as Mohan notes – this is similar to “Working software over comprehensive documentation“. Of course, we’re all used to modularisation when it comes to software development, it makes sense. And object-oriented design takes us further down the modular “plug’n’play” route. Leading on from this, modularisation helps us focus on the front-end value-add products and services, thus we are able to spend more time enjoying customer collaboration over contract negotiation (where contract negotiation includes all of the internal red-tape too).

However, the key take-away for me was found the last paragraph of the article:

Creating an agile enterprise is a transformation that needs to being at the top, with the leadership of the company. And it needs to begin with a questioning of the fundamental beliefs that drive the company.
…
The agile enterprise is risky to manage – you need to give control and ownership to partners…

Finally, Mohan’s box-out drummed it home:

Companies that have learnt to exploit technology can respond more flexibly to new trends and threats than their competitors (re-worded slightly)

Project Management

Uncanny horoscope…

1 Comment

I don’t normally read these things, but I had time to kill, yada yada yada, I know you don’t believe me, etc. but it’s true!

Daily Mail, Gemini, 23rd August 2005:

There seems to be not end of things to organise and ‘cope’ with. Make a list! Then prioritise it! Next, discard the inessential items. There are two ways to go now: into chaos or towards order. If you want to be able to enjoy the good things that are undoubtedly in you life, you need to make sure you don’t waste valuable time on things that don’t directly contribute to you happiness and well-being. Concentrate on really important people and tasks. You’ll be amazed at what you accomplish.

Now, either the writer is short of material, or he has just returned from a Scrum course. Either way, it’s uncannily close to the truth…and it works if you’re not a Gemini!

Project Management

A problem shared…

1 Comment

Way back in 1995, Kevin Cauble wrote a great article, Two Principles of Conversation. It was republished over at developer.*.

I particularly like:

Principle 1 – There is much to be gained by sharing your experiences, ideas, and problems with your peers.

I like it for a number of reasons:

Firstly, who are the best folks to estimate how long a piece of software will take to write? Answer: the folks who’ll be writing the software in the first place. Sharing your experiences, ideas and problems with your peers will ultimately improve your estimating ability and that has to be a good thing. There’s more about this topic in this blog post: #5 – Whose schedule is it anyway?

Secondly, a problem shared in a problem halved. Share your problems and other folks might/will come up with answers. It’s a good idea to make sure that you air your problems in a suitably qualified peer-group, otherwise you might get some poor answers. But nonetheless, problem sharing is a good thing, there is much to be gained from it.

Thirdly, it helps focus the mind such that you solve the right problem. All too often, and this is especially true if you find yourself isolated or working alone for period of time, your mind will play tricks on you and make you believe that you’re solving the right problem…when in fact you’re not…you’re off solving the wrong problem. Simply talking about a problem can be a real eye-opener and can result in a “seeing the light” moment whereupon you recognise that you were about to spend time working on something that wasn’t part of the solution.

If you don’t fancy reading the original article and are just a tiny bit curious about what the second principle was, here’s the spoiler:

Principle 2 – Managers HATE to see software practitioners conversing with one another.

I might write more about principle 2 later, however in the meantime, I would recommend that you read the article: Two Principles of Conversation.

PM#, Project Management

PM#8 – Multi-tasking is evil

2 Comments

“Nobody can do two things at the same time and do them well.”

Don Marquis

Clarke has often lamented about how multi-tasking is evil, something that was emphasised in #7 – High workload means lower productivity…

Humans aren’t multithreaded, therefore we can only do one thing at a time (this applies to men and women, please don’t be shocked or surprised).

Overlapping activities vs a three-course meal
Invariably, the more work that you pile on an individual or the more work that he or she accepts, you’ll find that individual attempting to multi-task under the premise that they believe they can do two or more things and do them well. Most of us struggle to cook a healthy meal, getting the timing right such that the meat, the vegetables and the potatoes are all ready at the same time eludes us. So why should we expect the same individual in the workplace to be able to manage three work basket items at the same time and with the same delivery date? Unless the three work basket items are trivial, we should endeavour to work with the individual and ensure that the three work basket items are scheduled such that there is little or no overlap.

Why do we find ourselves multi-tasking?
Multi-tasking, it seems, is forced upon us because there is a fear that employees will either take too long on a task or will complete it early and have nothing to do until the next task is issued. If you’ve got staff like that you should fire them and hire some staff who like challenges and who like endorphin rushes when they start something and finish it…at which point they’ll go off in search of the next challenge. Keeping an employee or developer busy seems to be fairly normal – we all moan about how much work we have to do…instead of moaning (or blogging as some might say), go and start a piece of work, progress it in small bite-sized chunks. Not all tasks need 2 hours, 2 days or 2 weeks to complete – those that do can be broken down into smaller more manageable tasks that are easier to swallow (read: easier to start). When you do break a larger task down, do be sure to follow each of the sub-tasks through to completion…and don’t lose sight of the parent task (i.e. don’t be distracted and lose focus!)

Respect the schedule
We find ourselves multi-tasking because other people don’t realise that we might have a schedule (a sequence of events/tasks that we’re trying to follow). Other folks will happily e-mail you, telephone you, walk up to you and [in the words of Scott Adam’s Dilbert] “expect you to drop whatever you’re doing and work on their problem”. Quite how you tell these folks that they are upsetting your carefully crafted schedule (even if it is written on the back of an envelope, whatever works for you…) is likely to be a personal thing and something that varies from organisation to organisation. Whatever you do, other folks have to understand that you are not sitting idly by your telephone or inbox waiting for them to contact you…you have work to do, you have a schedule, you have deliverables. Multi-tasking or task-switching will make you less productive which has a spiralling effect on the health of the project and your own health.

However, being seen to have a schedule and offering to fit their request in to your schedule is likely to win you some points too. Find out when these other folks need you to do their work by, then negotiate to fit it in: it’s very probable that with the thought that they’ve offloaded work onto you, the other folks will be happy with a negotiated date that suits you more than them…after all, you are saving them doing the work in the first place.

As soon as other folks realise that you’re working to a schedule and that they are part of that schedule, your multi-tasking or task-switching instances should reduce. Over time, those other folks will learn to approach you in less disruptive ways, e.g. via e-mail, knowing that you’ll “schedule it in and get back to them”…well, that’s the plan at least. I’ve enjoyed some success with this approach, it does depend upon the make-up of your team.

Pseduo-multi-tasking?
This might sound like I’m contradicting the purpose of this post, but it’s not, trust me. Despite heavy workloads, most of us are guilty of some degree of procrastination. We’ll delay or put off starting a task because…because it’s too big, because we don’t understand part of it, because it’ll take a long time to start and finish. Fine, either break it down into the previously mentioned smaller tasks or just start it. I’m using this approach to ensure blog posts are published: I simply start a blog post and save it drafts. Every so often I’ll spend a few minutes updating the blog post until it’s ready to be published. It’s easier to find a few minutes here and there than it is to find a few hours. Obviously this approach is only useful where tasks can be tackled in this fashion.

In this series:
PM#11 – Management By Shouting Loudest (MSBL)
PM#10 – The truth is best…admit it…
PM#9 – Avoid duplication of effort
PM#8 – Multi-tasking is evil
PM#7 – High workload means lower productivity…
PM#6 – You were right and I was wrong
PM#5 – Whose schedule is it anyway?
PM#4 – Start it…finish it
PM#3 – Use e-mail properly
PM#2 – Focus on the project
PM#1 – decision making

PM#, Project Management

PM#7 – High workload means lower productivity…

1 Comment

My friends and colleagues over on the SellingAgile group were discussing productivity recently. Tony and Clarke were at the heart of the discussion, it went a little like this:

Tony made an excellent post, too long to quote here, but I particularly liked this:

In the age of interaction-centric systems, it’s all about speed. Forgo the false god of utilization. Concentrate on speed and concentrate capacity, so that those valuable software products and the mountain of moola that each of them can bring might arrive today rather than tomorrow.

To which Clarke asked:

Are you saying that if everyone is busy all the time then they will actually be a slower at doing things?

To which Tony responded:

Yes, Clarke, if we ensure that we have active projects enough to guarantee that every developer has project work available, then we _CAUSE_ the whole system of resources to work at approximately half its sustainable speed. Management teams worldwide are wasting approximately half of the capacity of their development teams and, consequently, half of their development payrolls.

It became clear that some folks believed productivity is low because we’re overloaded with work.

Basically, this boils down to the fact that software developers (amongst others) rely on creativity in order to do their jobs well. Without suitable periods of “down-time”, work simply moves from one task to the next with little regard for “can this be done any better?”

Tony then went on to make this remarkable statement:

Think of multiple marathon relay races. We have one team and many marathon relay races for the team to run. If we schedule the races so that one race must end before the next race can start, then our team doesn’t get to finish very many races per day or per week or per year. So we surely want the races to overlap. But for each of our runners we absolutely do not want his/her segments across races to overlap. That would force the runner to jump from track to track and race to race without handing any baton to a downstream teammate. So, we overlap the races, but we don’t overlap any one runner’s segments across races.

Today, due to our unfortunate and grossly inadequate understanding of interaction-centric systems, we schedule the STARTS of our races far too closely to each other. This guarantees that every one of our runners is always on some one track or another, running at least one race and usually several races simultaneously. Then we require our runners to make progress simultaneously on all their active races, by failing to prioritize the races. This forces each runner to hop from track to track and from race to race repeatedly, before the baton of any one race is transferred to the next teammate. This is multitasking in all its ugliness.

Clearly multitasking is absurd in the context of relay races. But it is no less absurd in the context of product development. Yet this absurd behavior is precisely what we cause when we strive to maximize utilization. The resulting lack of performance is a tragedy of our own making.

Whilst folks think that having a steady stream of work is good, it seems that we worry about a number of things:

  • that we won’t have time to complete the current task (and do it well)
  • that we won’t have time to complete the next task
  • this appears to be a recursive worry

So, my take on this discussion resulted in this:

  1. Start something.
  2. Focus on it using decent chunks of time.
  3. Do it well.
  4. Finish it.
  5. Don’t allow yourself to be distracted by “what’s coming next”. Don’t flutter from one task to the next and back again.

Leaving an activity in an unfinished state will cause further distraction as your mind will play tricks with you, you’ll be worried about the unfinished tasks whilst you are working on current tasks. Break your tasks down into manageable chunks (task time average = 30 minutes), proceed to start each task and finish it, allow yourself some downtime (if you refer to it as slack, it’ll be consumed by the project, avoid using the word slack). Doing less work should will actually make you more productive.

Related to this:
How much pressure is required to make somebody more productive?

In this series:
PM#11 – Management By Shouting Loudest (MSBL)
PM#10 – The truth is best…admit it…
PM#9 – Avoid duplication of effort
PM#8 – Multi-tasking is evil
PM#7 – High workload means lower productivity…
PM#6 – You were right and I was wrong
PM#5 – Whose schedule is it anyway?
PM#4 – Start it…finish it
PM#3 – Use e-mail properly
PM#2 – Focus on the project
PM#1 – decision making

PM#, Project Management

PM#6 – You were right and I was wrong

2 Comments

If you make a mistake, I’d like to think you would be man enough to admit it.

The trouble is, and I’ve seen this in so many places, there are a lot of folks out there who seem to be unable to admit that they made a mistake. I’m sure that we’re all guilty of covering up a the odd faux pas here and there, but there are folks out there who take the cover up to new [stellar] levels. These stellar levels include such things as poor decisions or incorrect decisions (more here) and choices that have led to projects going off on a tangent for months on end all because of parochial approaches that prevent acceptance of the bigger picture (i.e. focusing on one small part of the project without understanding the project as a whole).

Saving face is not all that important, doing the right thing is. In a project-based environment, saving face for long periods is detrimental [to the project]. When driving, if you accidentally take a left instead of a right, you will endeavour to correct the mistake as soon as possible…you shrug your shoulders and get on with the course correction. Please take this analogy to your current and future projects: if you make a mistake, your cheeks go red, you blush, whatever, please raise your hand and announce your mistake. Team members will thank you for it, the project will run smoother and will stand “one more” chance of coming in on time and/or on budget.

Whatever you do, don’t try to ignore the mistake, cover it up or keep running with the mistake as if it were normality. And accept that team members might point out the mistake and ask you to do something about it: don’t fob them off with pithy excuses whilst you insist that you are right and they are wrong. Project rarely have “get out of jail free” cards, if you think you’ve got one please be aware that the card expires very very quickly after use: expect to be found out. Long running cover ups or long running changes in direction are catastrophic for the project and the team member morale. Do not think of yourself, think of the project and the team members (learn from what Derek Laud had to say about a lack of selfishness) – it’s not your project, it belongs to the team and the end users.

Don’t ever be afraid to say: “you were right and I was wrong”, it’s the best thing for you, the project and the team members. And say it as early as possible (mistakes and oversights are typically cheaper to fix earlier in a project).

In this series:
PM#11 – Management By Shouting Loudest (MSBL)
PM#10 – The truth is best…admit it…
PM#9 – Avoid duplication of effort
PM#8 – Multi-tasking is evil
PM#7 – High workload means lower productivity…
PM#6 – You were right and I was wrong
PM#5 – Whose schedule is it anyway?
PM#4 – Start it…finish it
PM#3 – Use e-mail properly
PM#2 – Focus on the project
PM#1 – decision making

Project Management, TDD

David Anderson interviewed by Robert Scoble

Channel 9 do a good job of getting life inside Microsoft presented to the outside world…here’s another fine example.

David Anderson, who has previously spoken at Agile Scotland meetings, was quizzed by Robert Scoble about “Agile Management and what we are doing with MSF for CMMI Process Improvement”.

Download and watch the video here.

The interview was littered with good advice, but I homed in on a couple:

developers don’t like two things

  1. interfering management, i.e. micro-management
  2. management not doing something when something abnormal happens

“Incremental development (Ed.with regard to TDD) only works when refactoring is part of the equation”, Ron Jefferies

It’s well worth the download, do take the time to watch it. Clarke sums David’s style up rather well: “David has a nice way of simplifying complex things”

General, Project Management

Derek leaves the Big Brother house…

Derek Laud, was evicted from Channel 4’s Big Brother reality TV programme on Friday. What he had to say once he left the house was somewhat inspiring, and he said it with considerable eloquence, grace and civility.

First and foremost:

…team effort is absolutely everything..and that’s fundamentally what works

Unfortunately, I’m not sure his housemates really grasped that concept on the whole (irony accepted). Team effort is everything: in a group of 10 or more people, it’s not worth being the only person, or the only two people trying to do all the work. Delegation is part of the game, but so it responsibility – it’s no use just sitting watching one or two people trying to do all the work, chip in a help them (especially if they ask you to!)

“team effort” == community.

Followed closely by:

it’s a lack of selfishness that’s very very important in life

The World doesn’t revolve around you. If you didn’t do your job, it wouldn’t be the end of the World. It’s not about “me me me” [cf].

I found this quote interesting and somewhat close to home:

other people are much better about making their problems seem more important than anybody else’s

Me me me. My problems are more important than yours ,listen to me, let me talk your ears off. Yes, a lack of selfishness is important, but so is taking your turn. Everybody has their problems, we just have to prioritise the solutions by importance and need.

And to finish:

listen more, talk less

Feedback is important, there’s little point soliciting feedback if you don’t listen to it and act upon it. Similarly, there’s little point in a one-sided conversation (which by its very nature is at least a two-way thing). And if team members bring problems to your attention, they’re doing it for a good reason, be sure you listen to them and act upon them.

Politics aside, a combination of Derek and Boris Johnson would revive the Tory party, perhaps? Just a thought.

PM#, Project Management

PM#5 – Whose schedule is it anyway?

6 Comments

There was an interesting discussion entitled “is it just me?” over here at Scottish Developers. My reply is here. Anyway, it preempted this posting in some respects, but I’m going to carry on with this post regardless!

Customers and management never seem to believe the estimates developers give them…time and time again, developers provide an estimate of how long a project (or task) might take, e.g. 12 weeks, only to be told (by the customer/management) that it will take 6 weeks. There are many reasons for this sudden shortening of the schedule…many of which revolve around the fact that the customer/management have promised their upstream customer/management something (a software solution) by a given date. An unrealistic date at that.

Who is more qualified to make schedule decisions that relate to software development? Is it the person whose job it is to actually “cut the code” (the most important part of any software project, no code, no project), is it the person who actually does the job or is it the person who has promised a piece of software to their upper management by a certain date?

Despite any potential previous bad experiences, customers and management should learn to trust developers more, they are the most experienced resource management tool a software project will ever see. They have excellent gut reactions, they know when something is “do-able” or not. They can reliably tell you whether something requires 4 hours or 4 weeks to complete. They know their business, inside out.

So why is there such disrespect for developers and the work they do? Why do I hear lots of sob stories revolving around late delivery, “he said it would take 4 days, it took 12 days, his estimates are rubbish”?

The simple answer is this: unless the part of the schedule that a developer is working toward actually belongs to him, realistically speaking, the developer knows he’ll not be able to meet the schedule but will carry on regardless. He has nothing vested in an arbitrary schedule that does not give him enough time to to his job properly. True, the developers will probably bust-a-gut trying to bring the project in on time, however as we know, invariably they’ll fail. But it’s not their fault. It’s the fault of the person who gave them the wildly inaccurate schedule in the first place.

Even if the schedule was remotely accurate and did have input from the developers, other folks exhibit a disturbing lack of respect for the developer and the schedule. A schedule can often be agreed provided that all or some tasks are distraction-free: this is easy to agree at the outset, but rarely happens during the project execution. Similarly, a fully-committed developer has no “resource gap” or free-time, there is no “contingency” in most projects. Therefore, you cannot duly expect to either e-mail or walk up to a developer and ask them to take on other tasks (for other projects) that aren’t part of the schedule…and since developers (and a lot of other good folks) find saying “no” difficult, they can often be [bullied] into saying “yes” to more work that will invariably knock the previously agreed schedule out. The trick here is not to offer developers other work – no matter how important it is to you (your top priority work isn’t going to be the developers top priority, he’s busy focusing on the project.)

Getting schedule buy-in from the developers is key – give developers the chance to form and shape their own schedule, let them break tasks up into smaller more manageable chunks that can be delivered over shorter periods of time, e.g. every 30 days or less. Don’t force them to buy-in to a [rolling] project plan that spans 6+ months – the speed at which the software business moves at, 6 months is far to far away: focus on what can be achieved now rather than later. Developers also need an endorphin hit every so often (cited as being every 2 weeks) – they get endorphin hits by starting and finishing a task, by seeing a piece of their code [go into production] in front of a user/customer or by visibly moving the project forward in some respect.

Analogy
When you last had you car serviced, you probably gave it to the garage for a whole day. I don’t hear about folks telling the folks who work in garages: “You need my car all day? No, you can have it for 3 hours. Can you get everything that needs doing done in 3 hours?” I’d like to see the state of your car once you get it back…may be not today, but in a few weeks time when you thought all that work had been done…

Example
I have a standalone application – a single .exe that runs on a per-machine basis. A client has requested that we “get it to work over the network”. For us, this is a big job, it requires changes to the backend database to allow the introduction of a user column (at least), transaction support, improved backup/restore, etc. To the client, networking an application is the simple matter of adding a login box at the start of the application. Since that’s all the client ultimately gets to see…”how can that possibly take N weeks to write?!” Perception and explanation are key. As developers we must learn to stand up for ourselves and learn to say “no” to unrealistic schedules: whoever is asking you to commit to such a schedule doesn’t understand how their car works, yet you won’t find them telling the garage to cut their schedule in half…unless they are themselves a mechanical engineer (versus a fitter), in which case they would need to be experienced software engineers in order to discuss schedules with you!

Need to cut the schedule? Well, why not cut the feature set?
If you have a pressing need to cut the schedule, at least negotiate with the developers over the feature-set that your hoping they’ll implement in the shorter time-frame. We know that “80% of a product’s value comes from 20% of its features” (originally from here), surely you can afford to cut the number of features in order to cut the schedule? Of course, now we’re in the realms of controlling the four success variables (cost, time, scope, and quality).

four variables

In the first instance the customer is allowed to select values for any three of these variables. The development team will then choose the value for the remaining forth variable. Ultimately, between the customer and development team there will be a series of compromises and trade-offs resulting in an adjusted set of values, or even trading of variables!

There are interactions between the variables. For example, increasing the time can allow for an increase in quality and/or an increase in scope. Another example might be a reduction in scope: it is possible to deliver earlier (less time) or cheaper (less cost) or possibly with more quality.

It is worth noting that the relationship between the four variables is a complicated one – it is not possible to reduce the time variable simply by increasing the cost variable. Nor is it possible to increase the cost expecting an increase in quality.

Crazy Schedules
Schedule pressure often sees shortcuts (or what are perceived as shortcuts) being taken. Instead of well-structured, reliable object-oriented code, being cut produced, prototypes are built as proof of concept…a little cut’n’paste then follows, prototype code suddenly becomes production code but only after crazy amounts of testing and re-work. It’s a spiral that requires a step back and a re-write to get out of, and may be more than one re-write at that. Crazy schedules will cost you considerable amounts of time and money downstream, they’ll also cost you the respect of your developers too.

Scott Berkun wrote an excellent book, The Art of Project Management, reviewed here, where he cites an example: your client in on the operating theatre table, the brain surgeon tells him that the operation he requires will take 12 hours…you won’t find your client turning to the surgeon and saying “no, you have 6 hours”…This just wouldn’t happen, I rest my case: if programmers or developers tell you something will take 12 hours, give them 12 hours (or more if you’re generous), it’ll protect your reputation, they’ll respect you for it and it’ll give your project more chance of success.

In this series:
PM#11 – Management By Shouting Loudest (MSBL)
PM#10 – The truth is best…admit it…
PM#9 – Avoid duplication of effort
PM#8 – Multi-tasking is evil
PM#7 – High workload means lower productivity…
PM#6 – You were right and I was wrong
PM#5 – Whose schedule is it anyway?
PM#4 – Start it…finish it
PM#3 – Use e-mail properly
PM#2 – Focus on the project
PM#1 – decision making

PM#, Project Management

PM#4 – Start it…finish it

8 Comments

As Dr.Neil Roodyn says, keep your task duration/time down to a 30 minute average (which means your tasks can be anything from 5 minutes to 120 minutes in length, it’s the average we’re interested in).

Just as important as the task duration, is the need to ensure that a task can be both started and finished. Long-running tasks do nothing for a person’s (read: developer) motivation and desire to focus on the project in hand. There’s little point asking a person to do any more if their in-basket/work-basket is already overloaded with tasks that have been started, but not finished.

I call this role Starter-Finisher, Dr. Meredith Belbin calls it Completer-Finisher. Either way, the job needs doing; starting can be easy, which is perhaps why Belbin believes the role should focus towards the end of the task, i.e. the finish or completion.

Completed/Finished tasks elicit feedback, feedback drives quality, quality drives customer satisfaction and customer satisfaction drives profit.

So, the simple statement that this post is trying to make: if you start something, finish it. Don’t let anybody distract you whilst you are completing (working on) the task, try and set aside a suitable chunk of time that is free from interruptions. Remember, the shorter the duration [of the task] the more accurate your estimate of time to complete it going to be. If you have to, break longer tasks, e.g. longer than 2 hours, into smaller more manageable tasks. Of course, you may need to remind folks that it is your schedule, not theirs, and that contrary to common belief you won’t drop everything to work on their problem.

In this series:
PM#11 – Management By Shouting Loudest (MSBL)
PM#10 – The truth is best…admit it…
PM#9 – Avoid duplication of effort
PM#8 – Multi-tasking is evil
PM#7 – High workload means lower productivity…
PM#6 – You were right and I was wrong
PM#5 – Whose schedule is it anyway?
PM#4 – Start it…finish it
PM#3 – Use e-mail properly
PM#2 – Focus on the project
PM#1 – decision making