It has been almost ten months since I outlined my last model of Project Management. The importance of having some kind of mental image about projects and Project Management may not come as a surprise. We are long due for an update on how I think everything links together.

Photography by Elvire R.

People Operating In A Group

Whatever your take is on projects, at the end of the day it is just a bunch of people working together to achieve a certain goal. During this endeavor to laugh, cry, pull pranks, play dirty tricks and have all other kind of behavior towards each other. If you are lucky they even work to reach the final goal. If you take everything away, and put people in the center of what a “project” is, you will see a group of stakeholders interacting with each other, just like any other group of people would do.
Read more

There is no Iron Triangle in Project Management. In PM we learn the holy trinity of the triple constraint, the concept that we are operating within borders, and that those borders are interdependent. Oh yeah, and "triple" or "triangle" indicates that there are three. Although the image is powerful to instruct, it is plain false. There are more than three types of constraints. Environmental, law, physical to name just a few in addition to things like time and money.

Read more

Different project circumstances require different approaches to ensure optimum effectiveness. As mentioned over and over again on this blog, it is the people who largely determine these circumstances, and you have to tailor your project approach to the particular situation. For this you can make use of techniques and tools from different existing methods by simply mixing and matching everything together in such a way that you brew the right Project Potion for the occasion.

Read more

There is not one way to make a great lasagna. Of course the basic idea is always the same, but depending on your taste, cooking skills and available ingredients you can have a lot of variations. Some use all fresh ingredients, make the pasta from scratch and spend several hours in the kitchen. I buy prefabricated ingredients and whip it up in several minutes. Both lasagna, but both very different.

Read more

Every element of a project method has a reason. If you know the reason, you know when to apply or use this method component. To explain this, I created a small sample using Scrum, and I turn to some global observations about it. I use the word global as I will not go into every little detail, but use the information that is available on the fabulous site ControlChaos.com.

Taken from that site:

Scrums Three Tools:

1. Backlog: Overall, by product line, by product, and by system an organization identifies all outstanding work and prioritizes it. This prioritized backlog list changes continuously and is updated and reprioritized continuously.

2. Sprints: Work increments where a team works on completing an identified, self-contained group of prioritized work. During the sprint, the work is not changed from outside the sprint, although as work occurs in the sprint, additional work may be uncovered.

3. Scrums: Daily meetings where a Sprint team meets to identify what work was just done, what work will be done next, and what is impeding work.

Here are some of my observations to add to the information given above:

1. Backlog: This list is the general planning tool. This is needed to provide feedback to the team members on what should be done, feedback to the users on what will be happening with their requirements, and feedback to management on progress and need for interventions/decisions. As only the items are planned for the current and/or next sprint (iteration), it can cause a problem with management that wants to have some statement about the long-term planning and cost. On the other hand, the underlying idea behind Scrum is that with unknown requirements (see 2. Sprints), every statement about the long term is almost useless. Only based upon the real speed of the team are time frames determined, and only for the foreseeable future. So the question is: Can you convince management that it is better to stay in reality and get involved in the process, or do they want to work with statements based upon feelings and hunches and have a false sense of security (some people prefer the latter)?

2. Sprints: Scrum uses an incremental approach to provide early feedback of some end result. The underlying risk that is covered here is uncertainties in requirements. By providing feedback in a working version as early as possible, this system allows the end users to view if the requirements are properly addressed. Also, a close involvement of end users within the Scrum team covers this risk. However, to be able to determine if the requirements are properly addressed, users will have to look to at least some version of the system that satisfies a certain business goal in its whole. As certain sets of requirements are dependent on each other, a real opinion can only be formed when a major part of the requirements are addressed.

If you look further in the sprint definition, you will find that it has to satisfy a sprint goal, which should be some business goal. So Scrum doesnt promote iterations just for the sake of iterations. The idea is to provide feedback, and if that is not possible in a good way, the increments dont make any sense.

3. Scrums: The Daily Scrums last no more than fifteen minutes. During the meeting, everyone on the team answers three questions:

1. What have you done since the last Daily Scrum?
2. What will you do between now and the next Daily Scrum?
3. Whats getting in the way of your doing your work?

This is to provide daily feedback to each other (including management) on the current state of the work and to address issues that need to be taken care of. Actually, these are just rules for an efficient meeting. Other methods also provide this, but the aggressiveness of the name Scrum has strong appeal.

From this short sample you can see that feedback on product and process are used to either reduce risks or satisfy the needs of stakeholders. You can also use the backlog technique in approaches other than Scrum. Heck, priority lists of requirements and risks can be found in other methods also. However, calling it a backlog is an in-your-face name, calling it exactly what it is. There are more methods that take an incremental or iterative approach, but always remember what it is you are trying to address, why you go incremental. Without having the sprint goal, the sprints would be useless.