Skip to main content


Showing posts from 2009

Outsource, Offshore, Offshelf – value in your IT department

Today I enjoyed a creative workshop with strategic leaders of our company. Almost all were collectively of a similar mind on one topic which had me soul searching for the remainder of the day.

Aside from confusion over terminology, the common theme was to not build things within our own IT department if we could buy the software from another source, saving money and getting it quicker.

During the meeting I felt duty bound to point out that off the shelf software was still written by actual people and then spent most of the flight home pondering the wisdom behind the notion of ‘any software, as long as it isn’t written by you guys’, or rather that was how it felt for me, to hear their opinions on the topic.

Perhaps it’s difficult for us in our IT department to consider buying software and integrating it into what we already have because we know too much about how this could go. Given our recent experience of a user base that wants highly customised software we are sceptical of their abili…

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…

Trust and Collaboration

Any project management methodology will teach you that to be a good project manager you need to write everything down and get everything signed off. That way the "legals" are bullet proof, you have evidence that the customer asked for it and anything not written down is completely out of scope.I admit to taking this position on numerous occasions myself.At some point in most IT workers careers they have been burnt by scope creep. The delivery date is set but the customer needs much more to be delivered in the software than you have built.Most IT workers would have stayed late for nights, weeks, or grueling months to squash additional scope into software deliveries. This usually is a result of a number of bad news conversations, some you may recognize sound like this:IT worker: You didn’t ask for that [feature/function]Customer: I may not have asked for it specifically, but it’s not going to work without it. How come you didn’t know that?IT worker: erm….let’s ask the Business…

Waste in Software Development

I’ve been dipping into ‘Lean software development’ a little and have become very interested in waste detection. I have plenty of ‘a ha’ moments when I read about examples of waste in software development, but sometimes I wonder if authors talk their topic up for dramatic effect. Here are three examples of wasted time and effort I found by paying attention for just one day at work.

We have regular status meetings when it’s getting close to releasing software in our department. We discuss any issues that are putting the release at risk, but mainly we discuss any defects that are outstanding and our chances of fixing them in time. During one of these meetings I enquired about the quality of software in general. “They found a severity 1 this week” somebody mentioned. I was interested and asked for more information. Turns out the severity 1 defect was found in BAT, however when the business was asked they reported that no one ever used this function/pressed this button. Some code(!) was bei…

Six things you should ask yourself before you adopt agile practices

1. Who cares? Who wants it? Is your customer asking for a more agile approach? Is Agile the latest flavour sweeping the floor? Has someone new arrived in your department with fancy ideas? It’s always a good idea to collect together, bat around the topic, share experiences positive and negative. Identify the like-minded people who are going to support this kind of change. It’s a people-change as well as process so you will need your pals.2. What will your development teams tolerate?Do you have agile fans in the development team, or active doubters? Architects can find it very threatening to advocate not doing big upfront design. Some developers simply loathe the idea of pairing on code. IT teams are densely populated with introverts and some find daily stand-ups and high levels of collaboration with business people too confronting. Happily these issues can often evaporate over time, but I have witnessed quite a lot of resistance to agile practices from development teams so it’s very wi…

Quick Resource Levelling with Microsoft project

This tip is for those times when you are messing about with your MS project plan, with tasks already allocated to resources, and you are trying to resolve resource conflicts.

I currently maintain a resource plan of 45 resources in MS project so I have become quite practiced at doing this exercise, below is the fastest way I have found to tackle it.

First tip is, I would never leave it up to MS Project to resolve resource conflicts for you, it will not optimise the use of people’s time as it can't swap resources on tasks and so will push your date out too far – to the horror of your business sponsor. It’s usually better to attempt to level resources yourself.

Perform these steps to "set-up"

If you are levelling resources you will need to flick back and forth between the resource usage and Gantt chart view several times, easiest way to do this is to select View > View Bar. This gives you the view icons down the left pane (see pic), and moving between views is one button cli…

Some General MS Project tips

I’m a self-taught MS Project user and certainly no expert, but I do know that it’s a good idea to spend the least amount of time using the tool as possible; here are some simple things that help me do that:1. A general MS Project planning tip is to have a good old pencil and paper with you, jot down the things you are trying to do and work through them sequentially whenever you update your plan:e.g. - Allocate next phase dev tasks- Add dependencies- Include new Change Request- Add Julian's training leave- Update % Complete on regression testBecause it’s such a fancy tool, it’s easy to become distracted, go off on tangents and forget to do basic things, so a systematic approach (I find) helps. If something occurs to you while you are say, identifying tasks, e.g. you notice a dependency crop up, then write it down on your paper and come back to it, best to finish identifying all of your tasks first.2. When ever I start a new plan I do the following things:Google for public holidays …

Alexandra Stokes' Software Misdemeanours

I arrived with a jolt in the IT industry on April the 21st 1997, I had finished my final year of university as an exchange student in Nottingham, UK (from Monash University in Australia). I was culturally enriched from my UK Uni experience, it was a time of great partying, house sharing, fun and music and ‘Brit Pop’ was peeking. I could fake a neat English accent, I was ready to work and too broke to buy a ticket home.

I got a job as a analyst programmer for a UK consulting company (now US and called ‘Keane Ltd’) and worked on a couple of Workflow and Imaging projects. My first big project where I had to produce some code of substance was a traditional waterfall project at British Airways, and it had lots of other characteristics that made it a disastrous prospect - it will no doubt feature as it’s own article on this blog- at the time I recall it wasn’t a pleasant experience.

Now as a crusty sage with 12+ IT years under my belt I can look back and pin-point the reasons why it was a mes…