Lessons from my first Project as a Project Manager
-
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/dpoole/lessonsfrommyfirstprojectasaprojectmanager.asp
-
Hi David,
interesting article!
Lesson 1:
True, give the customer one finger they want the whole hand 🙂
Lesson 2:
Maybe the most important of all. Though administrative overkill for the project manager and sometime childish, it will save your head one day!
Lesson 3+4:
Necessary!
Lesson 5+6+7:
Communication is the key to success. Internally and externally. Try, seeing it from the customers point of view. In most cases, the customer's management is deciding about a new project. So, here's your first group of persons to talk to.
But management normally isn't actively working in the project, but the employees. The second group of persons and to my believe another key to success of the whole project. If you can't get motivate the 'normal user' to work with you, your project will fairly be doomed to die. Have you ever considered what a project means to a 'normal user'?. It means more work, besides daily work. They must make clear what they do, how they do it, and what they want. Meaning they have to put it a lot of brain (they don't actually get paid for this extry work
). The third group of persons is your internal project team. Normally they are motivated to the finger tips, but you have to translate that what the customer needs into something your development team will understand. Sometimes this isn't easy.I think being a project manager is like walking on the razor's edge for most of the time, but if you like to work with people it's an interesting job.
Good luck to your future projects!
Cheers,
Frank
--
Frank Kalis
Microsoft SQL Server MVP
Webmaster: http://www.insidesql.org/blogs
My blog: http://www.insidesql.org/blogs/frankkalis/[/url] -
David,
Excellent article and everything contributory to good management has been summed up neatly.
Just extending what you've already said - firstly, I am glad to say that I follow every single lesson that you have listed!
Also - every single month, we have meetings with our client where all items from the "project journal" are dicussed - this includes tasks completed, "sweeteners" thrown in by client/us, persistent/unexpected bugs that push the project timeline et al.. This keeps the client well-informed and happy that the people he is paying can account for their time in such (excruciating) detail!
I cannot agree more about shaking someone's hands when you want to break their fingers - I have about 8 users who all manage to irritate me in their own ways - however, I treat each one of them as someone special (sic!) and always make sure I respond to their emails/queries within 10 minutes of having received them - even if it is only to say "have reviewed your requests - will get back to you on this by COB tomorrow!" Prompt responses always keeps them happy because you have acknowledged to them that anything that comes from their desk is worthy of immediate attention and they have no idea that I'm secretly wishing them in a faraway place that is said to be extremely hot !
Keep up the good work and Happy Management!
**ASCII stupid question, get a stupid ANSI !!!** -
quote:
Also - every single month, we have meetings with our client where all items from the "project journal" are dicussedI forgot to mention this because my first project was supposed to be 6 weeks long. It is probably of no surprise to anyone that it was quite a bit longer, fortunately due to delays requested by the client.
We also use a tactic where one of our trusted developers speaks directly with a person using a particular attribute for the program. Again, this builds rapport and also gets a lot of work done without all the management fluff.
You have to be very careful with this approach because it can back-fire if the client is a very political animal. I've worked on a project where the client nominated person smiled happily to your face, tested the system properly, approved the bug list then bitched to her boss about the number and nature of the bugs. Fair enough if the bugs were major or numerous but the reality was that the bugs were "lipstick on chicken" type bugs.
-
Unfortunately, a lot of the bugs that are reported are the "lipstick on chicken" variety or complaints about shades of the lipstick used...
One of the main reasons why those d%$# users irritate the heck out of you and why it takes admirable restraint on your part not to wring their .....
**ASCII stupid question, get a stupid ANSI !!!** -
Excellent list of lessons learned that everyone should follow. Whether you are a PM or a developer. My wife follows these as a consultant, often having PMs that don't, and has had quite a bit of success.
In a world where many (most) projects fail or don't meet expectations, communication is key. My wife gets 3 or 4 letters written to her boss a year from customers who were overjoyed with her service. Not necessarily the work since technology is a finicky beast, but they love her service. I know consultants who have not gotten 3 or 4 letters in a decade.
Communicate as the first poster mentioned. It is key!
Steve Jones
-
Excellent article. One of the most concise yet useful pieces I've seen on the topic.
Karen Gayda
MCP, MCSD, MCDBA
gaydaware.com -
True. I would also say that you spend a fair amount of time writing everything. I prepared a project management document that presented the scope and how we would handle changes. I would have meeting agendas, and then meeting notes. I worked very hard to not be surprised.
I have managed several projects (about 11, but do I count the ones that failed two minutes after kickoff?). Customer attitudes and the time line are also important .
One of my customers was easy to work with, because he was interested in having something than having something with all the bells and whistles. You manage customer expectations.
General rule - always tell the customer bad news as soon as you know it. They have to trust that you are in this with them. And telling them that something they wanted will not work the way they want or it will take longer to create, etc, demonstrates that you have an interest in keeping them involved and that it is not a us against them atmosphere.
It is much easier to manage a six month project than a six week project. A compressed timeline does not allow much time for error.
The challenge is learning enough of the customer's business fast enough so that you can translate it to the developers.
Prototyping is also important. After the reams of the kickoff documentation sometime later you bring them into a darkened room and show them a mock up of what they want. This is a chance for the developers and the client to talk. "Oh, you want it to do this."
Establish milestones, when possible. Keep everyone involved.
Bonne Chance.
Patrick
Quand on parle du loup, on en voit la queue
). The third group of persons is your internal project team. Normally they are motivated to the finger tips, but you have to translate that what the customer needs into something your development team will understand. Sometimes this isn't easy.Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply