What are your project management hot spots?

TheServerSide tends to spend quite a bit of time dealing with the low level tasks of hacking out Java code and pushing application code out to the server. But this month TSS is looking at going a few levels above the programming fray to look into the trials and tribulations of project management. Of course, this does beg the question, "From a project management perspective, what are the key issues that impact the lives of the enterprise Java developer?"

Time Estimates? Team Collaboration? Project Staffing?

Perhaps the biggest issue is the inability of project managers to properly estimate development timelines, forcing developers into the demoralizing task of working against impossible deadlines.
Poorly managed teams can also generate explosive results. Whether it's a problem with staffing a project with properly skilled individuals, or poor communication of expectations and direction, bad project management can be the signature on the death certificate of a failed project.
But not every project is poorly managed. What are the secrets to success? What are the great tips that can be introduced into just about any project that can push progress forward and keep teams motivated? There is no doubt that TheServerSide readership could write a sizable book about the topic.

What type of insight can an expert like you provide?

So, for now, TheServerSide wants to hear your project management stories. If you've got a quick story or insightful tip, post it into the comments section at the bottom of this post and we'll integrate them into an article or two. Or, if you've got some seriously keen insight, TheServerSide is interested in turning that insight into a feature article. Think about it for a moment and send an article idea to me, Cameron McKenzie, the editor here at TheServerSide, at cmckenzie at techtarget.com

Project Management - It's an important topic for the enterprise Java developer.

In my experience, project management is all about managing risk and expectations (duh...). Almost all projects I've been involved in or watched go down in flames from a distance, failure has been because of failure to properly identify and assess risk and impact and failure to mitigate and provide (and get sign off for) fall-back strategies OR because the PM and the team failed to get a sign-off on scope and expectations.

The second part is extra interesting because I've seen time and again a project manager (or a team leader) clearly define the scope to the customer/business representative but FAIL TO REQUIRE THE CUSTOMER TO SIGN OFF. Then, when the sh*t hits the fan, the project will claim that "we clearly defined the scope" while the customer says "yes, but I never signed off". Communication is not enough, at the end of the day a PM has to put the customer against the wall and ask "do you accept what I have proposed".

Incidently, this goes both ways. Any developer with an ounce of wit can (and will) find reasons why the project plan or delivery schedule does not apply to him or her because they were never asked if they accepted the plan in the first place. I'm not saying this is right, but it's how a lot of people work. Make the development team part of the plan, from the start. Estimates should be well established (and formally accepted) by the team tasked with doing the work.

On a last note:

The PM is the guy or girl who, at the end of the day, is hated, hounded and shouted at by everyone involved in the project, both from below and above. The team will hate him or her for the "insance schedule" and the customer will hate him or her for "failure to deliver as expected and a complete lack of flexibility". So keep that in mind the next time you refer to your PM as that "business lackey who doesn't understand anything". Ask yourself, who would you rather have in front of you, your PM or the customer, who would gladly sell your kidneys if it bumped the ROI by another percentage-point.

Love your PM and he or she will love you back. If your PM askes the impossible, suggest an alternative that is reasonable. If the estimates are unreasonable, say so immediately. Not saying "no" IS the same as saying "yes". That's risk and expectation management.

I totally agree with respect to communication aspect. The poorer the communication, the more possible is it for a project to fail catastrophically. :) However, in the age of agile software development, getting a client to signoff for a scope is next to impossible. I wonder how this should be managed.

I totally agree with respect to communication aspect. The poorer the communication, the more possible is it for a project to fail catastrophically. :) However, in the age of agile software development, getting a client to signoff for a scope is next to impossible. I wonder how this should be managed.

I would say in the age of agile, client sign-off is even MORE important. Agile is not the absence of scope, just a more frequent (and hopefully controlled) adjustment to it. If you are working in an environment where securing sign-off on reprioritizations in impossible, then that is an environment that is, by definition, not agile. This is a whole different can of worms though, organizations and projects that believe agile is something you can just decide to use without recognizing (and implementing) the necesarry changes to the requirements and business decision processes.

That could be another lesson for the PM: Don't try to be agile in an organization that is not. If you're going to run an agile ship, you need complete buy-in from all stakeholders and a firm understanding of what the methodology implies.

I'd like to dispel once and for all this common misconception about the evilish project manager.

First of all, most project managers leverage on the senior technical team to gather proper estimates or use function point analysis models that have been prepared by their teams or have been refined in previous deliveries of the same technology.

Projects mostly fail for four reasons: scope, account managers, risk management and communication.

Scope - it is very hard to get the customer to sign off acceptance documents or requirement analysis. This because no customer's employee wants to be held responsible for having accepted a project deliverable. Using hardball tecnniques like freezing the project until these documents get signed off only produce the effect of raising the friction and having the account manager try to find unreasonable compromises.

Account managers - a real evil. They would do anything to please the customer; they do not really commit on the project because, in most organization, they get their quota at the agreement sign-off. So, their only problem is not to make the customer angry at any cost.

Risk management - it is natural that, at one point, the s*it hits the fan. PMs who have a contingency plan or a risk mitigation plan normally manage to keep the losses to a minimum; the others well... you know it.

Communication - the greatest evil. Lack of proper communication, at any level, leads to epic failures. From a developer unable to admit they are late on their schedule to business analysts unable to encompass the requirements or a project manager conveying the right picture to the management and the stakeholders is a motorway to disaster.

Technology? Java? Well, technology is mostly irrelevant. I know most of the people will disagree, but having people with the right talent and a solid understanding of the business and the technology make technology just a matter of estimates and therefore of economics and milestones.

Technology? Java? Well, technology is mostly irrelevant. I know most of the people will disagree, but having people with the right talent and a solid understanding of the business and the technology make technology just a matter of estimates and therefore of economics and milestones.

Very good point, and I agree completely. Some of the best project managers i know and have worked with know nothing (or at least very little) about technology. They could just as easily manage a road-building project as a software development project. What they DO know is how to ask the right questions of the people who DO know, and how to interact and communicate concisely and consistently.

PMs with technical knowledge are the smartest managers.

I have become very impressed by SCRUM as a time boxed and working approach to managing software development. If you SCRUM and XP from the trenches, you'll get the idea

Lead your team to undertake activites in the spirit of the activity especially in areas of unit testing and testing in general.

Attack hard any ego's that make the quieter members of the team keep silent.

Sack recalcitrant developers who don't fit the culture no matter how good they are they will drag your team down and to date, in my experience, their work is always average to bad.

Don't allow islands of information to form, maintain controll of the design, remember your team works for you not the otherway around. Its your neck on the line if goes wrong.

Check peoples code, don't let it get away from you and do it at different times of the week.

Obtain decent machines for your team, fight for good lighting and seating.

Always obtain proof of an issue, ask why somthing is the way it is before taking action.

Every action taken by you or your team should be justifiable to the world at large if you can justify it you can do it.

Always keep the dependents (Customers, line managers etc) in the knowledge loop..  (This one is a bit vague sorry about that.)

Cheers

I have nothing to add here. This pretty much says it all. Really, impressive.- Texas Lending