Wednesday, October 13, 2004

Why have a Project Management System?

During my earlier days, I would always wonder, why make a hassle by having a complicated, time-wasting project mgmt system. Just assign me the task, and I'll write notes, and it will get done. Well after 5+ years of experience, I have realized as boring as Project Management, it's really about preventing wasting of time and energy.

As I have learned, as I get more experience, is that being a good coder, is more than just writing good code. It means, mastering all the elements of a web development environment.

But today, we're talking about Project Management, or as I like to call it:

If you were psychic knew exactly what the client wanted, didn't have to waste time by asking any questions, and can just take a few minutes to generate immediate results.

Often, we are experiencing the matador/bull symptom, of seeing an attractive red cape to attack, but not seeing the matador's blade behind it.

This is where those who do not like anal retentive details, of what managing their assignments, are structured so that they are focusing the correct amount of time, on the correct elements that lead to a complete project that meets needs.

Let's analyze that last statement, "A Complete Project that meets needs."

First off, how do we make sure we really know what their needs are?

Secondly, since the person/people who have these needs are usually not the people fulfilling those needs. How can we make sure that we can meet those needs in the way the client wants?

Thirdly, about half-of-us, have to deal with feature-it-us, where in the middle of the project, someone wants to add new features that were NOT a part of the original discussion, and the rest of us are do not have to face it.

Where being Bulls, we just want to kill the matador, or bounce him around at least, we do not want to dance around, or try for Bull gymnastics. Just to keep focused on our goals, and get there....

Where as Matadors, just have needs, that they use the cape and blade to communicate with, not always clearly, and not always decisively.

So we as Bulls and Matadors must come together to work out a way to solve our mutual problems.

The problems are:

1. What the heck is this application, this isn't want I wanted.
2. Hey I definitely said red here, blue here, and lots of green over here.
3. I spent days, weeks of sleepless nights on this project, and you still aren't satisfied?

So how do we solve this problem?

1. You must have a clear and precise idea of what the project is, what the logic flow is like, maybe have some drawings of what the pages look like. What colors will be used, etc. Imagine the coder doing the work, is deaf, blind and dumb, and that you have to use all your senses to completely describe this project.

2. Then as a coder, you have to plan step by step, in detailed fashion, how you plan to execute this project. The client went to all the work to detail out their request, now you must explain how you plan to do the work. I usually ask myself questions, to help fill this out, such as: What kind of graphics need to be created/changed, What database changes need to be done, What form processing or logic flow changes are needed, and how will I know. Use flow charts, diagrams, the more details, the easier it will be to follow your plan.

3. Now client and coder sit down, and review the Project Plan, to make sure the coder's idea of the project are the same as the client's. And then you can go over how long each step will take. What priority this project has over any other work that needs to be done. Then the client either approves or disapproves the Project Plan. If approved, start coding/executing the plan, if disapproved, then must re-start Project Plan to fill any missing spaces, or to clear up any miscommunication.

4. If approved start executing the project plan.

5. Debugging, at this point, as you iron out the bugs, create a functional testing checklist- A list of items that help the average joe, know whether the changes done were accurately done. Coders know code, but end-users know whether they were able to balance their checkbook or not. So help your code testing, by identifying what functionality this new project adds/changes, and how to test the success/failure of that change/addition.

6. Functional Testing, preferrably, the client or a fellow coder, or anyone who has not looked at or worked on the application. You want someone with a clear mindset evaluate the success of your new application. You repeat steps 4,5,6 until all functional testing, says GO!

7. Deploy Mechanism, we each have different development/production environments, but it pays to have a system/person that deploys the code to the right servers at the right time. Remember to turn Trusted Cache off, to make the code active.

8. Test Again on Production, using the Functional Testing Checklist, to make sure that everything works as smoothly on production, as it did on development.

Then document all of this, so you can organize, prioritize, and learn from each project. I mean, wouldn't it be nice, if you were working on the same project as you did 6 months ago, to have that documentation available to help remind you of what work was last done on that application?

Remember this isn't about being Anal Retentive, it's about avoiding communication mistakes.

What kind of miscommunication mistakes have you experienced? Or do you hate Project Management? Please comment.


  1. Anonymous10:44 AM

    interesting timing of this post, as this has been a subject that has been on my mind a lot lately. Our business is relatively small, but busy, and I'm starting to think we could really benefit from using Project Management software. Do you have any suggestions as to systems i should check out? I dont think it has to have a huge feature set, as we are a small design and web development studio.

  2. Anonymous10:47 AM

    Thankyou for your Informative Post.

    Keep up the Good Work.

  3. The key with this is to have a system first, and then software if it helps afterwords...

    It also depends on the style/personality of the developers, some developers will just not work at planning, communicating and documenting their thoughts on the project.

    If I were you, work with your developers, to come up with a system that makes sense to them, and then determine how you want to document that process.

    I mean there's really two parts of this, helping developers be aware of changes in their priorities, and the need to manage developers, in assigning projects.

    At the very least you can create word documents, of what documentation is needed at each step of your process. Then store that in an intranet, or use a commonly shared email folder.

    I have tried MS Project 2000, and any software is going to be a huge learning curve, to get it the way you want.

    Which is why I've mostly created intranet's to document, prioritize, communicate all about projects.

    In fact, having your team, spec out an intranet to help document, and go thru the steps correctly, can be a great team-building excercize.

    But in the end, Project Managmenet will only work well, if the people who manage and use it, are diligent in following the process.

    Also, in my experience, keep an eye on your process for any future improvements, no process is perfect, and takes time to perfect...

  4. Anonymous10:28 AM

    You make some good points, even if some of what you say is a little hard to understand. I'm guessing that English isn't your first language.

  5. Actually, english is my first and only language. While I am still learning to improve my writing skill.

    My goal has always been to share what I know, while still trying to learn..