project planning

Take a More Agile Approach to Problem SolvingYour managers want you to estimate features or projects months or even years in advance. But the work changes—or the code changes, or the people on the project change. What you thought might be a reasonable estimate four weeks ago looks wacko when you revisit it in six months. What can you do?
Why You Should Take a Bow When You Deserve OneIf the project you're managing goes better than planned—you finish ahead of schedule, under budget, or with greater results than expected—you might be inclined to chalk it up to luck and not want to draw attention. But here's an argument for why you should make sure people notice and you get credit.
The Mismeasurement of Software

Having participated in a number of unsuccessful metrics programs throughout his career, Lee Copeland has identified and distilled four key principles that help prevent the mismeasurement of software. Evaluate how your metrics work against these four principles. Do you need to make any changes?

Lee Copeland
A Tale of Two ProjectsLarge IT projects are challenging. Complexity is hard to estimate well. Big systems are tough to implement. But when you're staring at a fast-approaching deadline and you know your system will not be functional in time to meet it, there are ways of handling the situation that are better than others.
Stop Making the Same Mistakes

We keep changing the names of the development processes we use, but we do not fix the fundamental error they all suffer from: the failure to set a date and control the scope of the project—including proper estimation of testing efforts. Customers and IT must work together to truly be successful.

Tips for Improving Your Geographically Distributed Agile TeamMany people on agile teams have at least one person who is not collocated. Those on collocated teams indicate that more of their projects are successful; those on far-located teams have the highest number of challenged projects. What can you do if you're part of a geographically distributed team?
Design Each Team’s Project to Optimize at the Program LevelIf you are part of a program, it’s not enough to design your project for your team. You have to consider the needs of the program, too. Each team needs to ask itself, “How do we deliver what the rest of the program needs, as the program needs it?” Aim to meet deliverables—not control your people.
Playing Devil’s Advocate: Use Premortems for Your Project’s SuccessMost teams could benefit from having a devil’s advocate—someone who would help the team identify weaknesses in their thinking and seek changes that would prevent or minimize adverse outcomes. A project team can become its own devil’s advocate by using premortems before the project proceeds.