Category Archives: Project Management

eXtreme Tayside – Second Meeting

Last night saw the second meeting of eXtreme Tayside. Interestingly, and this is not an uncommon pattern with user groups, not one of the folks who attended the first meeting (late November 2005) were at this meeting!

It was held at Dundee University’s new Queen Mother building. More information about the building can be found here. We were lucky enough to get a tour of the building which was rather interesting despite the fact that the original architect used the name “pod” to refer to the building’s various sections/pieces. The design appeared rather original and despite the lack of sun-blinds, offered some excellent features. As an aside, it also provides a home for dmag.

Anyway, we discussed a number of things, possible locations, venues, session topics, etc. Each person introduced themselves and told us a little bit about what they did and provided some insight into how they became interested in ‘agile’.

One thing that did come out during the introductions was the fact that test-driven development and continuous integration are rather popular. Gary mentioned that his firm use the notion of a “broken trophy” that gets given to the person who breaks the build – an interesting phrase that caught the attention of most of us. Naturally this reminded me of Dr. Neil Roodyn’s red screen/green screen that he demonstrated to Scottish Developers during a July 2005 presentation.

Given the reaction it got, I can see broken trophy entering the eXtreme Tayside vocabulary!

Five seconds can save you up to £1m

Computer Weekly reported today that Barclays introduced a five-second cut in their call centres that should save them up to £1m over five years.

I’ve always been a great fan of reducing the amount of time it takes to do something, especially in a commercial environment because time really is money. If I can re-design a form layout such that you (the user) can do something with less mouse movement, or with few keystrokes, then I’ve effectively saved you some time…and thus your employer some money. Of course, tracking this saved time is somewhat difficult and can actually take so long, it negates the time saved. However, if you are able to track it and quantify it, you might be pleasantly surprised.

Design with the customer in mind (or preferably, present in the process!)
I recall writing a time and expense administration application for my employer, circa 1998. The existing paper-based process required us to fill in four sheets of paper in order to record our expenses, mileage, hours, overtime, etc. For a frequent traveller, the time taken to fill in the four sheets of paper could easily amount to 3 or 4 hours, or half a day…each month. You might not think that’s very much, but when you factor in 400+ employees, of whom about 300 will spend 3 hours per month dealing with their time sheet, that amounts to 900 hours or 120 man-days per month.

The application enjoyed lots of “little” time-savers. If you worked for a couple of hours on one project, 15 minutes on another, etc. it would display a hyperlink that automatically setup the hours input form with however many hours (or fractions) were left over. It would track your mileage readings from month-to-month – for some reason our paper-based approach required the vehicle’s mileage at the end of the month and at the beginning of the next month, which are one and the same! For expenses, it would remember the places you went to regularly, remembering the VAT no, what you bought (meals, tickets, etc.) It had a simple “copy for today” option that allowed frequent entries to be duplicated for use in the current day – useful if you found yourself going to the same place on a frequent basis. And it offered a simple Excel export which prove useful when creating client time-sheets or invoices. Lots of little things, tweaked via customer input, and a lot of time was saved.

Despite computerising the existing paper-based process to the letter (that was the specification), the application meant that even the most complicated month could be processed in less than 60 minutes, often a lot less. Of course, these figures are based on observation rather than hard facts, so a pinch of salt is required. That said, the time savings were “of that magnitude” and weren’t something to sneer at. But what did we do with that time saved? Well, one might suggest that the time saved could be spent on billable projects, in which case not only have we saved the time, but now it becomes revenue generating.

The question is: “what do we do with all the time that we save by using IT effectively and efficiently”? I imagine the question is both rhetorical and recursive…in a Dilbert sketch Scott Adams noted that any time saved as a result of IT is simply re-invested. I suppose this is just human nature, nonetheless, application usage scenarios are something that we all should consider when we’re looking at form layouts. And of course, the customer is with us every step of the way. The customer should be the first folks to react to an efficiency gains that you (as designer/developer) have to offer – after all, you are in the enviable position of being an “outsider looking in”, perhaps you can see things that they can’t, you bring to the table the ability to think out of the box.

Related Posts
What’s your most optimal process?
Jon Boxhall posts an amusing tale of a process that is less than optimal (via Mark Wilson).

Going Native with John Seddon and Systems Thinking

I had the pleasure of attending a John Seddon session last night. The event was organised by the Lothian Quality Forum and held at Standard Life. It was intended to be a Q’n’A session based on John’s earlier “Show” held at the EICC in October 2005. However, since only three attendees out of about 40 had actually attended the Show, John gave us a brief summary of the Show and some excellent eye opening advice.

John’s work in the Systems Thinking domain has some overlap with the work of Mary Poppendieck who promotes Lean Software Development. Having attended Mary’s course and read some of John’s work, and now attended a session, there are definite synergies between the two. (There you go, the word “synergy” can be used for something good after all!)

John had one slide. It came from page 11 of his book, Figure P2: Changing Management Thinking. On the left hand side we saw Command and control Thinking, on the right hand side we could see Systems Thinking. John made reference to each side throughout his pitch.

If you’ve read John’s book, you’ll know about the two types of demand: value demand (which has some profit related to it) and failure demand (which ultimately is non-profit). Failure-demand manifests itself in command and control architectures in the form of meetings and reports, neither of which are able to get hold of the causes of a particular problem (despite current command and control practitioners repeatedly trying the same thing over and over again expecting a better result each time…I believe that’s one of te definitions of insanity).

“Managing people is waste of your time…management of the system leads to a paradigm change in employee behaviour”

John made good use of experts from the field, some of whom were his employees, other not. One of the experts, currently from Norwich Union, cited the story of new employee induction training. After eight weeks of training, inducted employees could only really “do” 20% of the job (in a call centre scenario). After some careful thinking, two weeks training on the 10% most common problems saw the inducted employees performance improve considerably. Of course, for the 90% of “out of the ordinary” issues, escalation to a more senior employee prove to be the solution.

Standardised procedures seem to be the panacea to all our woes; they are seem as devices that can control the work. Standardised procedures actually see costs being driven up. In fact any attempt to control an [employee’s] activity has the same negative effect (costs go up). Indeed, standardising procedures in a service industry serves only to drive costs up – they cannot handle the variety and failure-demand that is inherent. In manufacturing however, standardised procedures serve their purpose. The continued practice of standardised procedures and traditional command and control structures essentially describe a “management factory where the turkeys vote for Christmas”. Not good.

“Beware of work amplification processes, additional and/or excessive work-flow

“The fish rots from the head” – this was a quote that I was unaware of until today. And I’ve since found The Fish Rots from the Head by Bob Garratt in my local Waterstone’s (which, I note, links directly to Amazon now…). Anyway, the crux of the quote stemmed from the fact that unless the man at the top realises this fishy fact, the command and control architecture will never go away, inefficiencies will remain, employees continue to appear to the be low performers (in reality, it’s the work that is the low performer, not the employee – the employee doesn’t change, the work does). I thought that this was a great quote, it certainly explains a lot of things, putting a good analogy on to a common problem.

On the subject of outsourcing, John and I share a similar view: outsourcing means work will come back to you in some shape or form, it’s a boomerang. Of course, fans of outsourcing will tell you it works, but they fail to take into account the true end-to-end cost, they fail to consider the additional transactions and the boomerang activities that introduce costs into the system. John places considerable importance on understanding the cost of service, end-to-end. You wouldn’t want to outsource, especially if you can do it cheaper yourself.

Never codify method – traditionalists believe that solutions stem from “more tools more training”. Wrong, wrong, wrong: we should work on the problem instead of identifying or creating a tool. Improve the derived value by deriving or determining the real cause of waste (hint: meetings and reports won’t help you here).

“Economies of flow are much better than economies of scale. ” UK government office are attempting to promote economies of scale, all they are doing is driving waste into the system.

John discussed the Womack and Jones books and left us with a strong read recommendation for The Machine That Changed the World by James P. Womack

Determining predictable demand is key. Optimise. 60-70% of demand is the same thing – train against this demand, reduce the end-to-end cost. Understand Demand. Study demand, it “opens the whole system up”.

Lastly, John left us with a “selling” tip:

“Don’t try to sell Systems Thinking – rely on folks getting curious about it and wanting to learn more (by doing)”

[Thanks again to Clarke for the invite, and to his colleague Fiona for letting me tag along as Vision‘s guest!]

Freedom From Command and Control: The Toyota System for Service Organisations, EICC, 11th October 2005

The event was an outstanding success and by popular demand a DVD of the show will be available shortly.

Lean times for online gambling

Infoconomy’s publication Information Age, November 2005, Lean times for online gambling, highlights a Lean/agile success story.

Mention of “emphasises face-to-face collaboration over documentation”, “product management team sits side by side with programmers so they can see what is needed as they go along”, “Daily five-minute morning meetings review yesterday’s achievements and the day’s plans”.

It’s a short article, but picks up on a few important points.

On contractor value, internal vs external development

Earlier, I wrote about my thoughts surrounding what is essentially outsourcing of a given function…thoughts that were firmed up after I had been reading Joel On Software.

I’m pleased to see Richard Jonas follow it up in his Internal or External posting. I have to agree with Richard’s comments, the decision to “in-source” or “out-source” on a project-by-project, or function-by-function, basis has to be made using all the information available (I can’t think of situation where this wouldn’t be true, although we all see such decisions being made without such consideration). And, it is important to note that some projects/functions are inherently meant to be outsourced.

My original posting was prompted (apart from via Joel), by a letter in Computer Weekly dated 20th September 2005 on the subject of “Do contractors offer better value for money?” The author notes that contractors rates of pay are typically twice that of permanent employees. He goes on to state that hidden costs such as bonus, pension, employer’s national insurance, recruitment fees, cost of human resources, accounts, payroll, taxes, holiday and sickness actually make a contractor better value of more flexible. Are these costs really hidden? Surely most businesses know exactly how much it costs to have an employee sit at their desk carrying out their function? No? All these hidden costs, the opportunity cost of having somebody else sitting at the same desk carrying a potentially more profitable function, etc. Surely? Clearly there are two sides to scenarios like this, the author of this letter sits on the side of contractors, whereas I seem to sit on the side of permanent employees…

On the premise that hiring a contractor is analogous to outsourcing a project/function, let’s follow that notion for a while…

Are contractors better value and more flexible? Insofar as the contractor doesn’t [usually] get embroiled in the internal politics that some many permanent employees do (although not through choice I might add), the contractor is free to focus on the task in hand, they can spend 90%+ of their working day on the project/function. Therefore, on the surface, they appear more productive that permanent employees. They’re getting the job done faster, possibly better, but not necessarily cheaper – twice the cost remember, folks will see that as being “more expensive”, unless they are able to understand that the contractor may have taken less time to complete the piece of work (although the work is unlikely to be completed in 50% of the time it would take a permanent employee to complete).

Unless the contractor is able to “hit the ground running”, it’s very likely that some mentoring will be required. Mentoring is often a service delivered by a permanent employee…their costs must be factored when assessing contractor value. Indeed, there’s often an element of re-work involved if a mentor or supervisor is involved. Despite best efforts, I’ve seen the work of contractors being “finished off” by permament employees. Similarly, I’ve seen mentors/supervisors grimace at how long recently in-bound contractors take to complete a known to be simple task (this is more obvious where the mentor/supervisor would normally have performed the job the contractor was brought in to do).

Where the function/project involves the development of a piece of software, it’s very rare (in my experience) that the ultimate end customer actually uses the software the day they are issued with it. The day that they are issued with it may well be the contractor’s last day, in which case who fixes the customers snags? This is less of problem where the customer has wanted to or has been involved in the development process all along, something which is very desirable but rarely happens in traditional software development shops. Often the mentor has to “pick up” the customer’s snags and fix them. This is a double-edged sword. The mentor is nowhere near as familiar with the code-base as the contractor. This will lead to increased start-up time, i.e. the snag will take longer to fix. It will also lead to reduced quality, the mentor may think that they have fixed the snag without realising their fix may have repurcusions elsewhere (yes, practicing test-driven development and having a suite of tests would help, but we’re talking about traditional software development, not agile!)

Contractor flexibility is evident as a suitably qualified/skilled contractor will lend themselves to any platform, any language and their curriculum vitae will be a work of honesty, not fiction. However, the business may find itself paying a contractor to learn a new skill that puts the said contractor in a more marketable position for their next contract. Not good. Similarly, the said contractor completes the function/project then moves on to a new contract. Whatever the contractor had to learn in order to complete the function/project was a skill that went with them…that may well have been a potentially proprietary skill that would have been better value if it remained “in house”.

I’m standing by my original thoughts: if a piece of work, a function or project is considered “core” to your business, subject to the decision making process noted above and in Richard’s post, it should be kept in-house, i.e. internal. Proprietary intellectual skills that give you a business advantage, give you a means of adding value, give you the edge, should remain in-house.

Managing Iterative Development Using Scrum

I delivered this session at the UK’s first DeveloperDeveloperDeveloper day on 14th May 2005. My slide deck and elementary backlog spreadsheet are available here.

I’ve recorded a blogcast (my first) that demonstrates how the product backlog spreadsheet works. I had a cold whilst recording this, hence the occasional cough’n’splutter! I’m hosting the blogcast myself for now, just until I see what happens to the bandwidth (if it moves, I’ll update this posting). Product Backlog Spreadsheet – the blogcast!

Also available over at here: http://www.blogcastrepository.com/Dev/Contrib/Cmurphy/ScrumBackLogExample_CAM.htm

The Art of Preparation…

Now, you’re probably going to think that I’m going way off-topic here, however stay with me, there is method in my madness.

Preparation is everything. I’m not talking about big upfront design, huge specifications or huge requirements documents. I’m talking about the basic preparation that we (not just software developers) need to do in order to do a good job.

If my memory serves me (and MSN Search confirms that it does), Sir Robert Baden-Powell, founder of the scouting movement coined the phrase and motto: “always prepared”. Preparation is something you can either do too much of, in which case cost increases for no perceived benefit, or you can do too little of it…and things go from bad to worse. Knowing when you’ve prepared enough is key… it’s similar to Antoine de Saint-Exupery’s famous quote:

A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.

However, there is a fundamental difference between perfection and preparation: You need not achieve perfection, for the customer may accept something that is less than perfect. However, if you fail to prepare sufficiently, you may not have that luxury, your customer may have seen you flounder early in the project and may not have the tolerance to accept a product that is less than perfect (despite the fact it is virtually impossible to deliver such perfection).

A slight aside
A long time ago, 1991 to be exact, I took six lessons in preparation for the IAM driving test. This is a driving test that you can actually fail and still drive away from. What caught my attention, even in 1991, was the amount of preparation that the test expects drivers to go through each and every time they enter a vehicle with the intention to drive. For example, there’s a whole “starting drill” and a “stopping drill”. During the drive, each and every drive, IAM drivers are expected to provide a running commentary of what they see and what the can expect to see (granted it’s best to make this commentary audible during the test in order to avoid a barrage of questions like “did you see X?”, “were you aware of the dustcart?”, etc.) A lot of folks have asked me what the commentary was like…so rather than create a new one (which wouldn’t be difficult in this day and age, MP3 players, etc.) I remembered the bits’n’bobs my instructor gave me…

My instructor provided me with a few things: a couple of heavily photocopied pieces of paper and an audio cassette that had to be returned. The audio cassette was a regular compact cassette that you and I might have recorded the “Top 40” on when we were a little younger (showing my age now, hey!) There wasn’t any evidence of copyright on the cassette, so I made a copy of it, and now I’ve converted it to an MP3. So, if you’ve ever wondered what the IAM driving commentary sounds like, you can listen to a short drive here [6.5MB]. (I have more commentary, send me an e-mail if you would like it.)

While you’re listening to that, here’s what those two photocopied sheets contained – the starting drill and the stopping drill (remember, do this every time you choose to drive somewhere):

STARTING DRILL

  1. Check The Handbrake For Tension.
  2. Check Doors Secure
  3. Seating Position
  4. Check Mirrors
  5. Seat Belts
  6. Static Brake Test
  7. Starting The Engine
  8. Primary Auxiliaries
  9. Windows
  10. Secondary Auxiliaries
  11. Mirror/Gear
  12. Mirror/Signal
  13. Shoulder Checks
  14. Moving Brake Test

STARTING DRILL – expanded

  1. Check The Handbrake For Tension. Do this by locating the handbrake with your left hand, take a firm grasp. press in the release button with your thumb and take up the strain ensuring the handbrake is on. then release the button, leaving it in the on position.
  2. Check Doors Secure. Take the hand furthest from the door, place it on top of the door at the window. nearest the opening edge, pull first then push. (The reason you pull first is to prevent an insecure door from opening into the path of another road user). Then ensure that your passengers secure their doors and report same to you.
  3. Seating Position. Check your seating position by placing your left foot against the bulkhead, this being the furthest your foot travels during the clutch pedal operation. Then with your arms flexed at the elbows, slide your hands from the ten to two position to the twelve o’clock position and then down to the six o’clock position to ensure your steering movement will not be restricted. Make sure you are not stretching or are too cramped and have a good accessibility to the controls. If you have to move your seat, warn any passengers behind you before moving. Do this even when moving forward.
  4. Check Mirrors. Check the rear view mirrors. The internal mirror is adjusted by using the thumb and index fingers of both hands, placing one at each corner of the mirror, taking care not to place any unnecessary strain on the mirror stern or of smudging the glass. line up the top of the mirror with the top of the rear window. The check that the external mirrors afford you a good view to the rear.
  5. Seat Belts. “The wearing if seat belts in this vehicle is now compulsory and as such must he used”. Demonstrate how to locate, fit and check them by locating the belt with your hand furthest from it, and pull some of the webbing. Then transfer it yo your other hand, pull out more webbing and at the same time locate the holder with your first hand and then insert the buckle into the holder. Whilst still holding the buckle and holder check it is secure by giving it one firm pull. Also ensure that all slack has been taken up in both straps and neither are twisted. Also indicate at that time the method of release. Then get your passengers to locate fit and check their seat belts in the same manner and report on the same. (Make sure they do it properly)
  6. Static Brake Test. Carry out a static brake test by depressing the brake pedal with your right foot for three or four seconds, to ensure that there is pressure in the system, and that it can be maintained. Report on the same.
  7. Starting The Engine. Take a grip of the gear lever by wrapping your fingers round it so the top of the gear lever just shows between your thumb and index finger. Depress the clutch. move the gear lever into neutral and once across the gate. With the clutch depressed start the engine. Release the clutch pedal slowly ensuring there is no breakdown in transmission linkage which might cause the vehicle to surge either forwards or backwards.
  8. Primary Auxiliaries. Now from left to right and top to bottom. select any minor auxiliaries which might be required at this stage, eg. heating and ventilation controls, rear screen de-mister and sidelights. Raise the engine revolutions to 1500 (fast idle) and get off your instrument panel from left to right, and top to bottom. Return the engine to normal tick-over speed.
  9. Windows. Ensure all windows are closed and have your passengers check theirs and report on the same.
  10. Secondary Auxiliaries. Select any major auxiliaries required. such as windscreen wipers. dipped headlights. etc.
  11. Mirror/Gear. Check internal mirror and in there is a suitable gap to the rear, select your moving off gear.
  12. Mirror/Signal. Check internal mirror again and if necessary signal to road users your intention to move off.
  13. Shoulder Checks. Carry out deep left and right shoulder checks prior to moving off ensuring that you explain the reason for doing so.
  14. Moving Brake Test. immediately on moving off report that the hand brake warning light has gone out(if applicable) and that your first consideration will be a moving brake test which will be carried out by building up the speed of the vehicle to 20mph in 2nd gear and then braking down to 10mph without depressing the clutch. Select a flat and level stretch of road with no inherent dangers and after nominating a suitable point. carry out the brake test. If on a hill the vehicle should be braked down from 25mph to 15mph. Then give a short report on the efficiency of the brakes. If the brake test cannot be carried out at that time, outline the alternative methods of carrying out the same. i.e. by braking early and firmly at the approach to the first hazard or by braking 10mph off your speed whilst travelling at a speed up to but not exceeding 50mph.

STOPPING DRILL

  1. Always ensure that you pick a safe place to stop.
  2. Prior to stopping, check the relevant mirrors and put your car on course early.
  3. If stopping completely off the main road, complete the full system. i.e. features 1-6 (from here) prior to leaving the main road. If, however, it is merely a parking area adjacent to the road or at the road side then continue through with feature 2 and in the last few yards prior to stopping depress the clutch with the left foot and ease the pressure off the foot brake.
  4. Immediately prior to the wheels stopping revolving, remove your right foot from the foot brake and then gently reapply thus preventing nose dip.
  5. Thereafter, and not against the ratchet, apply the hand brake.
  6. Move the gear level into the neutral position.
  7. Remove both feet from the brake and clutch pedals.
  8. From the right to left switch off any major auxiliaries and thereafter from left to right cancel all minor auxiliaries.
  9. Switch off the engine.
  10. Check your mirrors and if it is safe, depress the clutch pedal with your left foot and engage a suitable parking gear.
  11. Check your mirrors again and if it still safe remove and stow your seat belt in a neat and tidy manner not allowing the buckle to fly back and hit the glass. Ensure passengers do likewise.
  12. Again check you mirrors and look deep over left and right shoulders into to blind spots at the rear of the vehicle. Always tell your passengers to do likewise before they leave the vehicle.

So preparation prior to driving is important, it has health and safety implications. Similarly, preparation after driving is important too. There’s preparation pre and post-drive: projects should have a similar pattern, i.e. some preparation at the start and end of the project.

[Incidentally, these drills were scanned from its original A4 format using OmniPage 12.0]

Joel#1: Better, Faster, Cheaper

In an earlier posting I mentioned that I had been reading Joel On Software and that I might make the odd reference to it. Well, here we go…

For me, Chapter 35 (you can read the original posting here) has something very important to say:

If it’s a core business function — do it yourself, no matter what.

Actually, that’s a succinct way of putting it: the remainder of this post merely pollutes the eloquence of Spolsky’s quote (sorry!)

Spolsky suggests that we pick our core business competencies and goals, and do those in-house. Of course, this does suggest that you’re capable of identifying your core business competencies in the first place (although I’m sure that there are plenty of consultancies who will offer to help you identify them…for a fee and a retainer). What this means, in a nutshell, is this:

1. Keep all the good stuff that you do close to you, i.e. in-house

2. All the bad stuff that you have to do in order to do the good stuff, get somebody else who is good at it to do it, i.e. outsource it or find ways to do it better, faster, cheaper (more here)

Identifying the good stuff is simple: it’s the stuff that makes you money – it’s the stuff that’s on the invoices that you send to your clients. Invoices – that’s important too: don’t classify your invoicing process as part of the bad stuff. It’s a process that should be lean, agile, flexible and very efficient. The earlier your invoice goes out, the sooner you’ll get payment in (I know this is obvious, but I’ve read about some organisations who don’t understand this concept).

The bad stuff is anything that costs you money, and it’s something that you should optimise as much as possible. If you are able to reduce the cost of the bad stuff, it’ll make the profit margin on the good stuff even sweeter. This means that you’ll have to identify bottlenecks: any process that involves a single-point-of-failure (this might be a single person being responsible for dealing with too many requests, or it might be a process that involves double or triple handling of decisions/information) is a candidate for outsourcing or optimisation (faster, better, cheaper). It’s important to recognise that outsourcing the bad stuff might not be cost-effective, e.g. don’t outsource your IT function

However, it’s also important to recognise that some of the good stuff relies on the services and knowledge from secondary functions (these functions often produce a “value add service” that augments the client offering, sometimes to the extent that the good stuff can’t take place without the value add service). Once you’ve identified these secondard “good” functions, you may wish to start doing more of them (which should equate to either more profit or more client satisfaction: both are good, but there is a trade off – you need to get the balance right).

An example
If you are a hypothetical company that specialises in building industrial weighing equipment (perhaps for weighing a lorries and trucks), that’s your primary function. Your secondary function might be developing software that incorporates some intelligence into the weighing process, it might know about a lorry’s unladen weight for example. The secondary function might also extend into the client’s own management information system, perhaps feeding it with important information that can be used to verify the lorry owner’s credit worthiness, generate an automatic invoice (I told you they were important), post to ledgers, etc. You might think that it’s not part of your primary function, but the value add from being able to integrate with the client’s system is part of the good stuff – it’s something that should be nurtured and extended.

Spolsky’s closing paragraph presents a health warning that may have more truth in it that you believe:

The only exception to this rule, I suspect, is if your own people are more incompetent than everyone else, so whenever you try to do anything in house, it’s botched up. Yes, there are plenty of places like this. If you’re in one of them, I can’t help you.

If that rings a bell with you, then I too can’t help you. Sorry.

Respect…instead of blame culture

I read this week’s QSWeek magazine. Sadly you have to register (it’s free) to view content, and even to contact them…but that’s another story.

You might find the fact that I read such a publication a little odd, especially considering that I’m “in software”. I believe that it is important to keep up with what’s happening elsewhere in my employer’s business, hence I read many of the magazines that appear in the office!

Anyway, our Business Relations Director was interviewed and came out with a few useful gems worthy of note here:

We have to all work together to make projects succeed.

Projects don’t manage themselves, nor do they succeed if there’s only one person doing all the work…it does take team work, it does mean we all have to work together.

A lot of other things can be added to quantity surveying to make a wider offering to the client and I don’t think that will stop.

As many of you know, I have written “value add” applications for my employer, generally these applications augment the existing quantity survey, cost management or project management function that the primary business is providing. I’m sure that software falls into these “other things”, and I’m glad to read that it has a future.

Lastly, the If I ruled the world box-out really caught my attention:

IF I COULD change anything it would be to bring back respect for people and property. We have lost the ability to respect other people and get on with each other. I’m not going to say ‘bring peace to the world’ – that’s crackers – but if people went back to respecting each other instead of this continual blame culture, I think the world would be a much happier place.

I think that last bit strikes true, as I noted here and here, a blame culture isn’t a good thing: it doesn’t do your project or your organisation any favours.

PM#10 – The truth is best…admit it…

Project managers aren’t interested in listening to or reading about all the excuses that you might use to explain why something hasn’t been done. Nor are they interested in watching you try and get off the hook by listening to or reading about who you believe is to blame for your failure to do something.

If you haven’t done something that the project requires of you, or if you have made a mistake, the best thing you can do is admit it. The truth is best. Don’t send e-mails citing reasons why something hasn’t been done. Don’t write e-mails professing your apparent innocence and attributing blame on somebody else – if you haven’t done something, or if you can’t do it, tell somebody, tell the project manager. Feeble excuses don’t bring projects in on time or on budget, honesty is the only helpful option.

We’d rather know that something hasn’t been done, or that you can’t do it, as early as is possible – it gives us the chance to consider our options and still stand a chance of bringing the project in on schedule and close to budget. If you provide us with a barrage of e-mails with content similar to the above (blame-mail), the project is likely to incur schedule and budget hits (time is money).

If you admit the failure honestly, early and without blame-mail, you will be respected for your decision. It helps you, it helps the project manager, it helps the project, it helps the business.

The truth is best…admit it…admit it early.