Article: 10 Project Management Tips »
FERDY CHRISTANT - JUL 19, 2004 (05:50:00 PM)
Since I moved into a permanent position at my employer, my role in the organization has changed drastically. After developing Notes applications fulltime for three years I now hardly do any development anymore. Today, I manage several Notes/Domino projects and deliver consultancy to my customers and co-workers. I was never trained to do any consultancy or project management before, I simply dived into the deep. Instead of code, I now deal with customers and developers. Because it's been exactly a year since this big change, I figured it would be nice to evaluate and share what I've learned so far in the form of a few learning points. Much of this is stating the obvious, but maybe it will help somebody who is making a similar move. So here goes...the top 10 recommendations for beginning Notes/Domino project managers:
01. Know what you manage
Make sure you've played in the mud. If you've never developed for the platform, it will be much harder managing projects. Without the technical experience you will have to trust others when they make recommendations and estimates. Try to prevent this.
02. You're scum
When you move from a development role to a management/consultancy role, people will look at you different, even your old programming buddies. Face it, you're no longer cool. You're part of the dark side now. You're responsible for money and time, and for putting an unhealthy pressure on the technically skilled. Likewise, customers will no longer see you as the geek to solve all their self-caused problems. Instead, they will think of you as an overpaid consultant who tries to sell them crappy solutions they didn't want too late.
This is where you can make a difference. Try to stand next to your developers instead of above them. Treat them with the respect they deserve. Convince your customers by delivering honest advise, and deliver on time.
03. Don't plan on gut feelings
One of the most important things I've learned is that you should not plan using your gut feeling. Don't think you can plan multiple projects in your head and do all your estimates like that, you will be proven wrong eventually. Always look at the cold, hard numbers and make your decisions based on that. Whatever it takes, make sure that you frequently get a report on money, people, deadlines, holiday plannings, project statuses, etc. This really is the only way to make informed decisions and to know what's going on.
04. Don't give away all your cards at once
With this I mean two things. First, you have to make sure that you either have an answer or the room for things to go wrong. Example: Let's say you have made a deal with the customer that an application will take 100 hours to build. You could communicate it like that to your developer, but in that case you would have no room in case things turn out to take longer than expected. It would be better to tell the developer that he has 80 hours to build it, this way you have created room for things to go wrong. Plus, the developer will try hard to meet the 80 hour deadline. Obviously, the real trick is in convincing the customer it takes 100 hours, whilst it should really only take 80.
Second, it is important to have answers/alternatives ready. If you're in a meeting with competing parties, try to find out what their best interest is. Try to find out what they, and your customer, would likely ask from you. Prepare the meeting by finding the answers upfront. You will make a good impression at your customer when you can answer any question right away.
05. Figure out what the customer REALLY wants
This is again stating the obvious, but it could be the most important skill a good consulant/project manager could have. Customers hardly ever say what they really want, and it is up to you to find out. This takes good analytical skills, since you need to ask the right questions. There is no simple way to learn this. I'm sure there are classes for it, but real world experience seems to be the best teacher. Another approach would be asking the "why?" question until the customer stops answering them.
By the way, if you are interested in receiving a project management degree, their are a number of online and "offline" universities offering programs.
06. Be honest
Don't come up with excuses, accept the responsibility and come up with alternatives when things go wrong. In the end this will always work better. Be realistic as well. Customers will really appreciate your honesty, even when you are the bad news messenger.
07. Don't overperform
Don't build cool cool things the customer didn't ask for. In practice, you will rarely have time for this. It is better to use the room you have for making the application more robust and better performing. Component-based development is a best practice, yet don't come up with supergeneral components for your customer's supersimple problem.
08. Record your activities.
Back when I believed in the goodness of human nature, I would make deals with customers and developers by phone or personal contact. I couldn't have been more wrong. ALWAYS make sure that you have important commitments, deals, deadlines, arrangements, estimates and whatever else matters black-on-white. When a customer calls you, ask him to send his verbal request as an email afterwards to confirm it. This way you always have a strong case when people back out.
09. Don't be too flexible
A natural response when dealing with customers is to try to please them all perfectly, and lose your control over the process. Be flexbile, but in a controlled manner. Make sure that everybody in the process knows what their responsibilities are, including customers. If you don't do this, your own time schedule will be in serious danger.
The most important recommendation of them all. This is almost too obvious, but it really is not. This might be one of the hardest things to follow. It's so easy to get stuck in your routine and treat every project as if it is just another Model-T Ford rolling off the production line. What you really need to do is take a step back and see the overview. What are we doing here? Why do we spend so much time on this every project, how can we find better ways? Haven't we done a similar project before? Can we (re)use that? Are we creating islands here, perhaps we can share data with applications we have previously build? Is this really the best tool for the job? Is there anything on the market that saves us time? Curiousity is your top asset!
I have more, but I figured ten would be a nice number. Like I said, I know it is all pretty obvious, but I found the rules above to be working very well in the complex corporate environment I work in. Most rules can be applied to any software producing business, I guess. Reading them again I realize it doesn't even have a whole lot to do with Domino at all. Ah well.