Skip to main content


Showing posts from July, 2009

Is managing and controlling projects valuable?

Tom DeMarco is one of my favorite software publication authors. He still continues to blow my mind ten years after reading PeopleWare. Here's a short article by him that will challenge traditional thinking on project management.

It's certainly confronting to me, I often say 'the projects should pay for themselves'. The message here is the project should pay for itself many times over or why are you doing it?

I think this theory works for quantam-leap style projects, where a new product or revolutionary idea is marketable, or moves us on in software evolution. But what about day to day business software? So many changes I see are tiny incremental improvements that support a business, or make a user's life so much easier. Should we really abandon these changes if the gains are marginal?

It's a great thought provoking article, it certainly is food for thought when contemplating multi-million dollar green field builds.

Stand up, work better together

Whenever I walk around the office at 10 in the morning I feel a warm glow. It’s because most people in the department are standing up. We run daily Stand-ups for all of our projects

They are a highly effective tool for improving communication on project teams, my project managers are never a day away from knowing the health of their projects. I love Stand-ups because they are virtually free to implement and you can implement them for any project or team, whether agile or otherwise.

When I came to the company I started using daily Stand-ups on the project I was managing, one other PM was already doing them for her project. Eighteen months later they are part of the departmental culture, it’s how we work. When people from other departments ask me “why is everyone standing up?” I’m really happy to tell them and pass on the tool to them.

Simple tools that have such a powerful outcome are my favourites.

Spooking Customers

Here's a sport you may have played with your business customers when estimating some functional changes for them.

1. Easy change that you want to do = 1 day development
2. Medium change that you don't really want to do but can understand why they want it = 2 days development
3. Change that you know could screw your design royally, cause problems down the track, make future changes a nightmare = 4 hundred million trillion days development

Do you try and spook your business customers away from dangerous changes by over-egging the development estimate? Make it impossible for them to even consider backing the change?


Do you sit with your customer and explain the danger in their change, try to compromise and find some middle ground that achieves the solution for them without compromising the system?

We are all guilty of bamboozling customers with tech-speak on occassion, maybe it's time we created a forum with our customers and found a way to communicate our concerns hopes and dre…

My IT brain

Today in a meeting one of my MD's said to me "see that's where your IT brain get's you into trouble" when I was bitching to him about some departments not going through due process of putting their changes up for scruitiny against return on investment.

"Sometimes you don't want to jump through hoops and go through process, sometimes you've got to just get it in!"

Gotta love his flagrant bending of the rules and disdain for beauracracy :-)

When is a defect not a defect?

When the user never experiences it.

I once worked with a great QA manager called Will who used to say “If we find 200 bugs in test, and you guys fix them, then they never happened” which always tickled me. It was a way of agreeing amongst our IT-selves, that we wouldn’t necessarily advertise that the software was of poor quality until we squeeeeeeeezed it though the QA/fix machine and it emerged squeaky clean the other side.

We currently are going through a clean up of a large backlog of defects logged in our system, note the use of the term ‘logged’ which doesn’t necessarily mean experienced. When we go through our development projects it’s not un-common for us to stumble upon defects that are already released in our production software. When this is the case we fix them if we can, if timescales and deadlines are just too tight we go through a process of raising them as production defects. It seems like the right thing to do, we found 'em, therefore we hold our hands up put them on…