Yesterday was one challenging day at work. Let me start at the beginning. I woke up at four A.M. and my brain was thinking about work - specifically, I had two elements of system requirements that I needed to document. So, I woke up, started the coffee pot, booted up the work laptop and went to work. I paused long enough to eat some breakfast and then run through the shower. At about 7:00 AM I made the commune into the office and continued working. From 8:30 to 2:30 I was in a continuous series of meetings. I tackled email from 2:30 to 3:30, then headed out to meet Tony for a slice of pizza at Patxi’s (as always, truly excellent pizza). I worked email from my Blackberry through dinner, then headed home, came back online and worked until 6:30 PM, by which time I was completely and totally fried. I stared blankly at the TV until about 8:00 PM, then trundled myself off to bed and collapsed. I sleep through the night, pretty solidly, woke briefly at 4:00 AM, rolled over and went back to sleep until 6:00 AM, then got up and started the next day.
The challenging part of the day was the content - the hours were challenging, but they are always challenging. Once again we ran into the problem of the vendor software not quite working like the vendor set it did. The result of this is the specific answer you get depends entirely on who you talk too and since this influences the subsequent design decisions we end up with a lot of back and forth. Since this project has slipped three release dates (October, December, January) and the tail end of it isn’t going to go live until May, it is pretty safe to say that there were some major problems.
I can, and have, ranted and raved a bit about everything that was done wrong so I am not going to rehash most of that here. But, I did think I would share a specific set of problems that we’ve encountered. Recently, my immediate manager (who is very competent) opened up the doorway for an internal review of “what can we do better”. After the routine jokes where we wondered if we could fire our director, which would cure most of our problems, we did agree to settle down and put some thought into. I think there are a couple of areas where we can definitely approve.
Here are the things I am feeding back.
First, we need to start the project with the appropriate attention to detail. Very early on in the project life cycle you have to have your analysts sit down and go through the entire project individual item/object by object and ask a simple set of branching questions. Are we doing anything to this object? What are doing? What are the implications of that (what does this object touch)? If the project includes a thousand objects, you need to go through each one, one at a time, in detail. It is grinding work. It is detailed and devilish and time consuming - but it has to be done and it has to be done by the right people (the people who have specific knowledge of each object, it’s purpose, it’s function). If you fail to do this ground work, if you fail to lay the very foundation of the work to come - you will fail. You will fail because some of those objects are little landmines, waiting for you to make a mistake - to miss something or to change something that has unintended consequences, does not work as intended, does not work as designed, or simply does not work. This was the root cause of every single delay we’ve had on this project. There is no substitute for this activity and the earlier it takes place the better.
Second, planning did not adequately account for dependencies. In any system of systems, there are objects that are dependent on the object before it. As you adjust the system, you have to adjust the objects in the correct order. Yes, you can run development in parallel to make better usage of time - if you did the first foundational exercise completely and correctly. If you didn’t, you run the very real risk that your parallel development is going to fail because when the time comes for the pieces to match up, they don’t.
Third, we wasted a very significant amount of time and resources going back and forth, trying to do the foundational work when we were already deep into the configuration. We spent thousands of person hours configuring systems only to discover that the first issue here had not been done, so we then had to turn around and redesign and reconfigure. By my estimates the cost factor was about three times what an ordinary, efficient, project should have been.
Fourth, we spend a very large amount of time in meetings, and these meetings are not an efficient use of time. We need to run our meetings with more discipline, with an agenda, a carefully thought out list, tight control, and a focus on the agenda.
So, my advice for my immediate team, in terms of what we can improve is 1.) build the foundation carefully and deliberately, 2.) plan carefully with an eye to dependencies, 3.) focus on the first two items so there is no wasted time due to churn and burn, and 4.) make efficient use of meeting time.
No comments:
Post a Comment