Project Management Blogs

Constraint management is at the heart of Goldratt’s Theory of Constraints (TOC). This management process involves five basic steps [i] :

1. Identify the constraint
2. Exploit the constraint
3. Subordinate other activities to the constraint
4. Elevate the constraint
5. Avoid negative inertia and Go back to step 1

There have been many articles lately about the role of the BA on Agile projects. Some postulate that the BA role is closest to the product owner. After all, it is often suggested, they reside with and represent the business. They are in the best position to be the final voice when defining and prioritizing requirements. Others believe that the key role for the BA on Agile projects relates to testing. Since they define the requirements, they should complete the appropriate testing processes to ensure the final solution meets the requirements. I believe that neither of these is a business analyst role. That’s not to say that someone with the title of BA cannot play other roles as well. It’s just that when they are playing these other roles, they are not doing business analysis work.

Picture this.

You are in a software diner one evening after a long day at work. A tired and disheveled waitress walks up to you to take your order; gum smacking as she goes over the daily specials. Nothing really sounds good to you, but you are extremely hungry and short on time. She summarizes the possibilities for you to help with your decision-making. Honey she says,

You can get mediocre to terrible food fast or slow food that tastes good. But you can’t have both—good and fast food.

In my last post, I reviewed a most successful project, the Interface Initiative, and how the PM leveraged the Project Pre-Check fundamentals of stakeholders, defined processes and a best practice based decision framework to achieve great results and gain recognition from the stakeholders as a great PM.

Here’s an example of a project that could have used a great PM. Unfortunately, it was a challenged undertaking due, in part, to flawed incentive compensation. That’s way I call this post You Get What You Pay For!

Do you find that important projects that promise long term benefits continuously get postponed and often never get done?  We call this the perpetual back burner projects syndrome.

Some years ago I worked with a technical services group that found itself constantly postponing work on long term projects because they were constantly jumping on the short term, ad hoc projects that kept coming up day after day.  The short term projects were responses to service requests.  The long term projects were infrastructure changes, of which many would reduce the occurrence of or eliminate many of the causes of the service requests that kept the group from working on the long term projects.