I've Been Here Before, Haven't I?
January 23, 2008 at 10:00 am by Chris
As part of his general theory of relativity, Einstein suggested that the shape of the universe itself was hyperspherical, meaning that there is no center as such and that the universe would look exactly the same from any point within it. This would mean that one could potentially, assuming a very powerful telescope, look in a straight line through the full extent of the universe and end up at the back of one's own head! Pretty strange right? Very strange. What does this have to do with web development project management, you ask? Well...Sometimes I feel like I'm having this cosmic Einsteinian experience when I get to a certain point in a project- the point when I realize that despite taking every precaution and exerting much effort to avoid the mistakes of the last project, I've actually made many of them again, plus a few new ones! The site is buggy. It looks wrong in some browsers. Time is running out. Everyone is unhappy. It's at this point when I feel like I'm seeing the back of my own head and I ask myself, "how did this happen... again?" There are some troublesome aspects of most projects that will probably never go away. Things like debugging, multiple rounds of QA, and rescheduling will always be a part of project management because not everything is predictable. But some of these things are actually inherently beneficial to the project. 
Let's start with bugs. Bugs are actually not a bad thing (at least, not always a bad thing). In fact, bugs exist because when software is initially designed and developed, not every factor can always be predicted and accounted for. This means that when the first test is run, the bugs are the first indicator of those unpredicted issues and actually help the project to be refined. However, bugs get less and less appreciated the closer the team gets to an important deadline. This is understandable, but sometimes unavoidable because there are often bug-revealing factors that don't come into play until late in a project (delayed access to databases, new requirements, etc.). But if you can prepare your client for these unforseen issues, and bugs in general, everyone will be much happier. Think about it this way: when any company releases some software that is tagged 'BETA,' it is a general warning to any user that they are likely to encounter bugs of some kind. It's kind of like saying, "we know this is unfinished, and we can't promise that using it will be a flawless experience." But, when the software no longer has 'BETA' stuck on it, users are far less forgiving of bugs. For a case in point, I only need two words: Microsoft Vista.The first thing that any of our clients should know when a site is first released is that there will be bugs. This is pretty normal. In fact, most of the time the visual design is not yet applied at this point, so there is definitely a strong BETA vibe going on. I find that if our clients know that bugs are a normal part of the development process, for all the reasons I stated above, encountering them is far less disturbing. (If any of our clients got the impression that our sites would be completely bug-free the first time they were used, we'd be in big trouble.) However, they do rightfully expect that as the visual design is applied and initial bug reports are addressed, that the site will emerge out of "BETA" in time for launch. This all seems pretty straightforward, doesn't it? You're probably wondering, "what's the problem, then?" I agree, which is why I am often caught off guard when, during the home stretch of a project, things get a little tense and I do that bit of self-diagnostic wondering how this all could have been avoided. Often, the one thing that I know could have avoided this situation is the one thing we don't have: Time. 
In all of our project proposals, we schedule time for testing and QA. It is usually the last phase of the project prior to going-live, which means it is often the phase that gets thrown out when a project is down to the wire. What I've learned is that we need to be much more insistent that this phase is kept in place, even if that means the go-live date is delayed. After all, everyone knows that haste makes waste, right? Of all the phases that should have their full allotment of time, the testing and QA phase deserves it the most. Of course, enforcing this is much easier said than done. In order for this to really work, our clients need to feel that the testing and QA phase is just as important as we do. What I have realized is that when I find myself in that recurring moment of "I've been here before, haven't I," it's likely because I have failed to communicate how important the last phase is, and thus failed to win the client to that point of view also. Doh! Now, if only I could reach out far enough in the Universe to slap the back of my own head!We recently created a 'Project Anatomy' document (see left) that includes every possible step for a project that we might work on as a resource for the project managers. For some projects, not every step will be necessary, but following the anatomy as closely as possible will now ensure that testing and QA are definitely performed at various points in the process and are 'non-negotiable' even when time gets crunched. It's hard to say whether this will prevent every future project from bringing its manager to the 'back of the head' moment, but I'm confident that it will be a huge help. |
Tags: web-development strategy design project-management
 |  |  |  |  |  |
