Quality

My wife is constantly reminding our kids that they need to follow all of the directions when doing their projects and make sure that all of the objectives of the project are met.  But it that quality? I guess that really depends on whether you want to measure quality during the build process or whether you want to measure quality as at the end of the process.  I'm going to argue that in the IT field we need to measure it both ways.

Quality at the end of the process - the delivery of the application to the business client - is very important as this is how IT is predominantly measured by the client:  were my needs met and if they were met how well were they met?  If you don't meet the needs of the client it doesn't matter whether you built it ahead of schedule and under budget because the client is not going to be satisfied.  We don't do JD Power & Associates surveys of all of our work, but maybe we should.

Quality during the build isn't something that the client concerns themselves with, that much, but it has a direct impact on time and budget.  Fewer mistakes during the build process means a faster time to finish and a lower cost.  So, while it may not seem important it has a vital role in the cost of the product at the end of the process.  To be honest, this is where most projects fail to perform any measuring and this is where the most important information about the build process can be found.  Measuring the end result is fine for final reports and is something that you can parade around on your business card, but it doesn't tell you how well the job was done on a daily basis, just on an overall basis.

In my opinion, understanding how well the project is doing on a daily basis, the quality of the work that each person creates each day, is just as important as the end result.  But, hey, that's just my perspective.

Death March, part two

Let's talk about a death march again.  My note from last week seems to have stirred up a little bit of angst amongst the crowd.  Let's talk about some of the other characteristics of a true death march.

The project that I worked on had a requirement for a lot of people to be working on the project simultaneously.  To that end we converted a large room on the floor below us to a large "pod".  Affectionately called "The Pit", it housed twenty people in an area that should not have housed that many people.  To put it in a context that everyone could appreciate, there was approximately 22 square feet of space per person.  Go into the bathroom where you work and go into one of the bathroom stalls.  Imagine it about a foot wider and that is the amount of space that each person had.  You couldn't push your chair away from the desk if the person behind you had already done that as there wasn't enough room.

Accenture (Andersen Consulting at that point in time) had a strict dress code policy.  Shirt and tie with dress pants and dress shoes.  Always.  The Pit was not designed for twenty heat generating computer, twenty heat generating monitors and twenty heat generating people for extended periods of time.  With a southern exposure the room got warm.  Unbearably warm.  The thermometer didn't register above forty Celsius, so after the temperature went above that for a number of days in a row the dress code was relaxed, only for those that spent the entire day in the room.  (By the way, the highest temperature recorded in the room was fifty Celsius by a thermometer at my desk.)

My boss at that time once gave me supreme heck for leaving the building to get something to eat.  He expected me to stay in the building from 7:00 AM to 7:00 PM, even though he worked fewer hours and had air conditioning.

Lack of respect for the individual is a key component of a death march.  If you care about the people around you, if your supervisor cares about how things are going, if the organization as a whole understands what is going on and tries to alleviate some of the stress (paint ball parties, laser tag events, movie nights, pizza lunches) then what you've got is an unfortunate set of circumstances, not a death march.  Some projects have periods of high stress and high workload and that is, unfortunately, a common occurrence in our line of work.  How we and our associates handle the situation is what makes it a death march or a learning experience.

Is it just me or ...

Is it just me or do kids these days have a false sense of size and a false sense of what they need?  Maybe it's just me, but let me give you some examples.

• This developer came up to me and said that he was working on a huge project, it had over 20,000 lines of code.  When I was working for the WCB I had to recompile every single COBOL program that we had because we changed a copybook that was used in every single program.  I had to recompile 1850 programs with an average length of 20,000 lines of code and I had to do this in four separate environments, including production.  I recompiled approximately 150,000,000 lines of code.  Twenty thousand lines of code seems small by comparison.
• "I've got a huge database and I'm not sure that the database can handle something this size."  The database in question could fit on a single DVD - less than 4GB of data and contained no table with more than a million rows.  Compare this with a financial disbursement table that grew more than 10 million rows per year and had a history table that had grew by 20 million rows per year.
• "You guys need a bigger server.  My app requires four quad core processors."  A properly written application does not need four quad core processors.  I've been part of a system that had 1200 users, over 400 of which were considered "power users", serviced by two, dual 700MHz processor boxes.   Less processing power than a single web server we have today.  Considerably less and yet our applications push the current boxes to the limit for far fewer users!!!
• "My application has a huge user base:  200,000 people per year will access it."  So?  Let's say that people will access your application only on business days, and then, only between 8:00 AM and 5:00 PM.  That leaves 100 people accessing your system every hour.  That's not a big application.  It my handle work for a lot of users, but it's not a big application, particularly on the hardware we're running.

OK, That being said, it may not be the kids fault.  He could just be repeating what he is being told.  He might never have experienced anything Enterprise-scale.  He might just be a rookie.  Let's give the kid the benefit of the doubt, educate him on what an enterprise scale actually consists of and then watch him go back to his desk, thankful that he's not working on one.

Road Kill

Road Kill.  You know, the dead animals you see on the highway that had the unfortunate luck to step out in front of a speeding car/truck and get hit.  It's not a pretty sight.  Over the course of the past 20+ years in IT I have felt like road kill a number of times.

Most projects have timelines that they need to live by.  Sometimes these timelines are arbitrary dates, sometimes they are based on business processes and cycles that need to be adhered to and occasionally, every so often, they are legislated dates that have a tremendous social and political implication if they are not met.  In those rare cases when you are working on a project like this it might seem like a death march, but it doesn't have to be.  This is where the role of Project Manager is particularly difficult:  how do you convince the staff to continue working on this project while at the same time telling the business client that the dates seem a little unrealistic?

I've been involved in a number of projects where the target date was just totally unrealistic.  It was way too aggressive for the amount of work that needed to be done with the resources that were available.  Putting more resources wasn't going to work due to the start up effort associated with new staff and the decrease in productivity of existing staff as they helped out the newbie.  Working longer hours wasn't going to help because the team was already working 50%+ overtime.  This is where project managers bring out the Successories posters and try to motivate the staff with short little quotes.  I've even had project managers blatantly lie to me about the project:  "You'll only have to work overtime for the next four weeks and then we're back on schedule"  (It took six months) 

At the end of the six months I felt like road kill.  Most of the staff felt like road kill.  This didn't have to happen.  This didn't have to turn out the way it did.  The timeline was set in place by the client but, you know what?  It was flexible.  They wanted a specific implementation date so that they could start showing a return on investment for the application.  They were doing it so that it would have a bigger impact on the current years year end report.  Our management, so intent on pleasing the client, burnt out a considerable number of staff and presented an image to the local IT community of a bad place to work.

Sometimes you need to step back and take a look at what you're doing and see if it makes sense.  In my case it didn't.  Your case may be different.  If there isn't a hard and fast deadline that you need to meet, err on the side of the people and adjust the schedule.  Losing staff may be worse for your project than implementing late.

Diminishing Returns

What is the optimal size of a project team?

What is the optimal size of a meeting?

These questions have plagued people for years.  The egotists/dictators amongst the crowd will think that the best number is one.  If there is no one else to discuss things with then you will always get your way.  Unfortunately, getting your way is not always the best solution for the client, so we need to have at least two people.  Indeed, for most projects there will be multiple people involved ranging from project managers to developers to business analysts to the actual clients themselves.  So what's the answer?

I was reading an email this morning which mentioned getting business analysts, project managers, clients, Directors, project teams and the Deployment Team involved in a "little" project.  I almost collapsed when I read that part of the note, fearing a room that contained twenty five people, all of whom wanted their voices heard and none of whom were willing to budge.  I was quite relieved when I read the next couple of sentences and realized that the writer understood the "Law of Diminishing Returns" (The larger the group involved, the less likely you are to get consensus.) and had provided the solution:  representatives.  (Hey, this kind of sounds like democracy in action, doesn't it?)

Trim down the size of the meeting to a smaller number (research has shown that five to seven people is the best, with seven being a fairly firm upper limit) and have the people in the group represent various segments of the prospective user groups.  For larger projects the same sort of segmentation and representation also works wonderfully.  Split the overall project into small teams working on a specific problem.  Have related teams grouped together where a representative from each team will have a voice in a larger collaborative group.  This has worked well for major companies like Microsoft and IBM and consulting firms like Accenture.

The root concept is the same, however, keep teams relatively small in order to reduce the number of nodes of communication that each person is subject to and to improve the the overall feeling of ownership.

Adjusting to Changes

Sometimes when we create a new application and deploy it to our clients it falls down with a resounding thud and we wonder what went wrong.  It did exactly what they asked for and it does it in the same way as their existing application, but something falls flat.  What did we do wrong?

There are so many answers to this question that I could spend the rest of my life describing them, but let me highlight some of the things that are probably big contributors to the problem:

• Lack of Evangelists.  On larger projects what you need to do is really engage the prospective clients and get them really excited about the changes.  One of the ways to do this is to recruit members of the client group to be evangelists".  Apple first made this term popular when they started hiring evangelists (marketing people) for their hardware and software.  While you may not think this has a big impact, believe me, it honestly does.  By the time the application rolls out you have people in the client group who have seen the application, know how to use the application and are enthusiastic about it.  This really goes a long way to making the roll out a success
• Lack of fun.  OK, after you've finished scratching your head, think of this:  what is the worst thing about using a new piece of software?  Finding the bugs.  But what if you made finding bugs fun?  What if you gave out prizes or even balloons, for finding bugs?  A friend of mine, when her project went into production, had some members of her project team wandering the floors of the users.  They answered questions and, more importantly, gave people helium balloons when they found a bug.  It became a fun competition to discover the bugs.  Rather than being dismayed, the users were happy.  (Needless to say it was important for the project team to fix the bugs as soon as possible so that they saw results from their discoveries.)
• Lack of Communication.  Newsletters are so '90s, but they work.  Whether it is a formal newsletter, or a web page or even an email that is sent out periodically, keeping the clients informed of the progress of the project and what is coming down the pipe is so important.  By being involved in the process, even from a passive perspective, the client is much more likely to embrace the changes and accept the new application.

None of these things are new.  Projects around the world have done them for years and have done them successfully.  The biggest problem is knowing when you need to use any of these, or a hundred more methods, for your project.

Consistency and pudding

Consistency is an often overlooked attribute.

Consistency is what keeps many franchises open - if the food is good at one location, and the franchise is consistent in terms of quality, then every location should have good food.  Consistency is important in some food - have you ever tried pudding that was not the same consistency?  Have you ever wondered what was in there?  We rely upon consistency for driving - ever seen a set of lights go from Green to Red to Yellow?  (Colour blind people need not answer this question.)

Consistency is valuable in many aspects of an organization.  A consistent approach to resolving issues normally results in the average time of an issue decreasing.  Consistency in how projects are planned allows both upper management and staff a better understanding of what is currently on the go and what is outstanding.

Consistency in projects can also increase the quality of a project.  For instance, if people consistently run unit tests when they've made changes to an application the odds of an unexpected bug slipping in are greatly reduced.  Consistency in processes between projects allows for developers to go from one project to another with greater ease and allows for upper management to aggregate data amongst the projects as the data is gathered and reported in a consistent manner.

The new version of TFS (Visual Studio Team Foundation Server 2008) is a tool which is going to help us gain some consistency in our projects.  With a common build platform, a common defect tracking system, common processes, common work flows, and common reporting, the ability to aggregate data in a meaningful manner is greatly simplified.  The ability for someone to switch projects is greatly increased as they already know the infrastructure and the processes that are in place.  With consistency we will spend less time trying to customize something into a form that no one else uses and we will spend more time resolving the fundamental business issues that we are presented with.