Gathering Requirements: That it implies that you already know the solution to the problem. By collecting information, we determine the “real” problem(s).

Many of us have experienced frustrations with obtaining useful program performance data. It is not always an easy process of maturing project management and earned value management best practices…

Requirements are descriptions of the end-result of your project. They are a way to gain consensus on exactly what it should do, and impose some constraints as well.

Good requirements DO NOT impose a particular solution unless there is a valid business reason. Let me explain.

So, you have been hearing of the advantages of being a PMP and have finally decided to appear in the exam!

Great! Before you get set to prepare for this exam, you need to spend a moment verifying whether you are eligible to appear in it. Through this article, I will help you do exactly this.

So, what is it that you need to be eligible?

There is often a misconception that managing an IT project is difficult. Avoiding the common pitfalls of IT project management is not rocket science, it is simply a case of taking some sensible measures. This article identifies 5 killer mistakes of project management and their solutions.

Developers everywhere are in terrible pain. Why has it come to this? What can we do to make the world a better place for software developers and their children? This series of posts will address the pain!

The first sad, sad story….. “We’re 4 months in to a 5 month schedule and I just received the final requirements yesterday (and they’ve changed again!)”

Fellow blogger Craig Brown over at Better Projects asked “Why reverse engineer requirements?” in a recent post.

Anita Wotiz is the guest blogger this week over at the UCSC Extension in Silicon Valley Project Management blog. She published great post titled “An unrepeatable success?” Read it here.

It was great to hear about the project, specifically the lessons learned and trying to relate them to my own experience.

I wouldn’t write the first set of factors off as things that can’t be duplicated. Sure, it’s easier in some cases because these things fall into your lap, but these can be influenced to some extent. Paraphrased:

1. Good team (competent, cooperative) –A PM can sometimes influence who works on their project, and ensure they are competent. Cooperation and team spirit is largely influenced by the PM, in my experience.
2. Exciting work –Not every project is glamorous on the face of it, but the PM can and should figure out how to position the product being created to the team by selling them on how much value it will add for the end users, and how their individual and team contributions make it possible.
3. Full access/utilization of previous work –Again, this usually doesn’t fall in your lap, but it’s amazing to me how many project managers don’t spend enough time during the planning phases trying find previous work that can be re-used. Many seem to want to re-invent the wheel with each project.

As for the other factors, paraphrased:

1. Don’t constrain the project to a preconceived solution –Three points; I see this so many times, where the sponsor and stakeholders have a preconceived notion of what the solution should look like before they even fully understand the problem! Granted, sometimes there are real constraints that are necessary. I think it’s human nature to start coming up with possible solutions very early in the process, and difficult to avoid. Personally though, I’ve found the best results come from forcing yourself to focus strictly on the need/problem during early planning, including the charter, preliminary scope statement, and initial requirements gathering processes.
2. Good WBS creation and decomposition, bottom-up estimating –Bingo! This agrees completely with my experience about what helps make a project successful. I’ve had a lot of luck in the past using a delphi-style method of estimating, where we go through each task in a room with the experts who will be performing them, and each person writes down an optimistic, likely, and pessimistic point estimate. I take all the estimate sheets afterwards and roll them together, ask about any outliers, and can usually come up with pretty good ranged estimates with a solid grasp on standard deviation and confidence levels.
3. Management cost/time buffers available –I agree that it’s critical for the sponsor/customer to realize that buffers are there for a reason…they are not just downtime or waste, they are crucial components of a good project that can handle the inevitable risks that will arise.
4. Collaboration –It sounds like Anita was able to get the whole team to collaborate on scheduling by using post-it notes on the wall. I think that is excellent, although alternative methods may work just as well to have the team collaborate on schedule and task dependencies.
5. Iterative Development –This is a benefit I’ve used and seen in my projects too. If you can push out iterative releases that are functional, you can start getting feedback from the customer and make subsequent development based off a real foundation, instead of a theoretical one. Writing code to specs is one thing, but if you can immediately test it against an initial release of the pieces it has to integrate with, you’re way ahead of the game.

Dave Garrett recently wrote on the concepts expressed by Aaron Shanhar in his book, Reinventing Project Management. The gist is that the common triple-constraint model of managing cost, schedule, and scope is not enough. As I like to put it and in Goldratt’s words, necessary but not sufficient.

I have not yet read Shanhar’s book, but have a few initial thoughts based on Garrett’s description.

The notion feels right. I have observed a few specific behaviors that may come about because of the framework of incentives set up by the traditional approach. First, quality assurance seems to be an afterthought or necessary evil in many projects, if it happens at all. I agree with the notion that the triple constraints are efficiency-focused. They set up incentives to meet the requirements, even if those are the bare minimum. Many times, scope is reduced as a result of cost cutting efforts, and they are looking for whatever will provide barely satisfactory results. Activities are dropped without a thorough analysis of what the impact on quality, team morale, etc. might be.

Second, I have known many project managers to define success as sticking to the requirements, even if they are very bad requirements. There’s no incentive to put a lot of effort into quality requirements if a project manager knows they will still have met scope, schedule, and budget. In other words, you can have a failed project which meets all three constraints. Interesting….doesn’t sound like success criteria.

I agree we need a better model with which to think about projects holistically. I look forward to reading Reinventing Project Management, and learning more.

I recently read a new book by Curt Finch, CEO of Journyx, Inc. titled “All Your Money Won’t Another Minute Buy – Valuing Time as a Business Resource.” I have always been a student of time management, so I was delighted with the opportunity to interview Curt about the book. Please enjoy the interview.