Category Archives: lightweight projects

17 Beliefs For Project Managers

Bob Sutton is a management professor at Stanford, and publishes a useful blog, he doesn’t publish often but it’s always high quality content and perhaps most importantly, his work is grounded in empirical, research based analysis. It’s oriented towards managers rather than project managers, but there’s obviously a lot of overlap in applicability. Below are his 17 beliefs, which link to the related posts in most cases:

1. Sometimes the best management is no management at all — first do no harm!

2. Indifference is as important as passion.

3. In organizational life, you can have influence over others or you can have freedom from others, but you can’t have both at the same time.

4. Saying smart things and giving smart answers are important. Learning to listen to others and to ask smart questions is more important.

5. You get what you expect from people. This is especially true when it comes to selfish behavior; unvarnished self-interest is a learned social norm, not an unwavering feature of human behavior.

6. Avoid pompous jerks whenever possible. They not only can make you feel bad about yourself, chances are that you will eventually start acting like them.

7. The best test of a person’s character is how he or she treats those with less power.

8. Err on the side of optimism and positive energy in all things.

9. It is good to ask yourself, do I have enough? Do you really need more money, power, prestige, or stuff?

10. Anyone can learn to be creative, it just takes a lot of practice and little confidence

11. “Whenever people agree with me I always feel I must be wrong.”

12. If you are an expert, seek-out novices or experts in other fields. If you are a novice, seek out experts.

13. Sutton’s Law: “If you think that you have a new idea, you are wrong. Someone else probably already had it. This idea isn’t original either; I stole it from someone else”

14. “Am I a success or a failure?” is not a very useful question

15. The world would be a better place if people slept more and took more naps

16. Strive for simplicity and competence, but embrace the confusion and messiness along the way.

17. Jimmy Maloney is right, work is an overrated activity.

Book Review – Mindfire

This is the most provocative book I’ve read in months. The ideas contained in the essays are persuasive and it’s a fun, well focused read. Ideally, I’d like the book to be longer than 30 relatively short essays (hence 4 stars, not 5) but the quality bar is super-high and everything is well written in Scott’s energetic and personal style, and a does a great job of making you take a step back and think/reflect. The essays are short enough that even if one of them isn’t your thing, you’re pretty quickly on to the next one.

To give examples of essays they include topics like “How to give and receive criticism”, which describes how criticism isn’t just about your own views and a perspective and a single correct answer, but also about thinking how different people will interpret the thing that’s being criticized. Many of the essays tend to be motivational such as “The surprise inspiration of death” or “How to be passionate”.

As the author discloses, the essays in this book can also be found on his blog, but either because of the editorial work that’s gone into the book or because of simply reading it on my Kindle rather than a webpage I found it a much more engaging experience than hunting around on the web.

Overall, I really enjoyed this book and would recommend it. If you’re into the writing style of Malcom Gladwell or Michael Lewis then it’s a reasonable bet that you’ll enjoy this, and it’s sufficiently short and focused that it’s a very easy book to get through.

You can find it here on Amazon’s US site.

The Key To Personal Improvement

There’s a lot of thinking at the moment around using agile methods, quick prototyping, seeing what works and rejecting what doesn’t. In all sort of  circumstances this is a valuable approach.

However, there’s one problem at the personal level. Our memory, or perhaps more accurately, our decision making processes, aren’t up it.

In essence the decisions we have made in the past can shape our perceptions of the future, and most importantly, we may not even be aware of it.

It turns out there’s a fairly simple solution to this issue. Namely, keeping a diary. And now, with tools like  Skydrive or Dropbox it’s much easier for a diary to follow us around, assuming the presence of an internet connection.
The goal is not to document your deepest feelings, just to document what you were trying to achieve – before you know the outcome of the decision – ideally right after the decision occurs, hence before bias can be introduced.
Doing this avoids the unhelpful tricks memory plays on you and ultimately will make you a better decision maker. Peter Drucker is a strong proponent of this style of documented decision making to improve learning.

Asking Better Questions

The questions you ask determine the quality of answers you receive. Project managers should care about this more than most, because getting early information on how things are really progressing is the lifeblood of project management. It’s good to avoid leading or biasing questions by removing anything that assumes a particularly positive or negative answer from how you phrase the question. Even better is to use a question style that remains neutral and encourages comparison and reflection – for example by asking how the project is going relative to other project of a similar nature or at the same point from completion.

The Value of Iterative Prototyping

Nice video on the value of iterative prototyping and the limitations of an MBA.

SCRUM for Wedding Planning

Gregory Heller gave an interesting talk on using SCRUM for Wedding Planning at the Seattle Ignite event yesterday. Ignite is an interesting concept where all presenters get just 5 minutes to speak and this is made up of 20 slides at 15 seconds each. The slides are programmed to advance automatically so presenters are forced to stay on time. Despite the provocative title, the talk is encapsulates some of the key aspects of SCRUM nicely. You can see his notes here and the slides are below (though you really need the notes to make full sense of it)…

Eight Innovations For Project Managers

Many aspects of project management are tried and tested. For example, Gantt charting is the most obvious example. Below are more innovative concepts that are not so broadly used by all and might be useful to you. These aren’t changes you should introduce wholesale, but rather a list of ideas to experiment with on more of an ad hoc basis, depending on the needs of the project you’re involved with. Each idea links to the relevant blog post.

  1. Reference class forecasting – looking at similar past performance as the basis for estimates
  2. Pre-mortems – assessing what could cause problems before they happen
  3. Avoiding the Fred Brooks fallacy – adding more people to a project may actually slow down progress in the short term
  4. Aiming for more ideas rather than better ideas – great ideas come from culling and refining a large idea list, not from waiting for a single perfect shot of inspiration
  5. Setting ambitious goals – setting goals high leads to better performance
  6. Focus on the hard conversations – communication is key to any project, and the hard conversations are where the value is
  7. Consider outsourcing tasks – there is no reason that employees of your organization are the best people to execute all the tasks on a project plan
  8. Use burndown charting – a way to predict finish dates on certain projects with greater accuracy

The Value of Burndown Charts

Burndown gives you a robust way to figure out when your project will actually finish. It’s a core part of scrum, but really a lot of project managers can get value from using this technique.

Burndown is valuable because we know people are generally bad at estimating completion dates, so any estimation technique that contributes an objective estimate should be useful. If you already have a Gantt-based schedule, then burndown is likely a complement rather than a substitute for it because the two methods are fundamentally different, but are both help answer the same question – when will we finish?

Burndown hinges on a very simple equation:

Rate of change in work = New work added – work completed

There are two basic outcomes of this equation. If you’re adding more work than you’re completing, then the completion of the project is still some way off. If you’re completing more work than your adding, then you are on the way to being done, and burndown charting can give you an estimate of how close the endpoint is.

As with anything apparently simple, the challenges are simplified away. Here the main challenges are:

1. Ensuring that all work is defined at a similar level (for example work in a software project might be defined as a bug)

2. Ensuring that you actually have a way to measure when new work is added and existing work is completed.

And of the 2 items above (1) is actually much harder than (2). With any decent tracking system (2) should be straightforward, but on (1) work items will never actually be truly equal, for example I mentioned software bugs as a common unit to measure in, but of course not all bugs are equal, some can be fixed in 10 minutes, others may take weeks or longer.

Then generically any project has 3 phases.

  • Phase 1 – planning: work items flat or increasing
  • Phase 2 – core execution: work items increasing
  • Phase 3 – approaching finish – work items decreasing

The diagram above gives an indication of what this looks like over the life of a project, though of course no project is ever quite this pure.

Burndown is most interesting/useful in the final phase (the downward slope) because that’s when the estimates have most forecasting value.

Example 1

50 work items outstanding

1 work item being added each day (on average)

11 work items being done each day (on average)

So, net 10 items are being done each day and the project should be done in 5 working days (i.e. 50/10).

Example 2

200 work items outstanding

10 work items being added each day (on average)

15 work items being done each day (on average)

So, net 5 items are being done each day and the project should be done in 40 working days (i.e. 200/5).

The examples above also imply that burndown only tells you when the stock of existing work will hit zero. Obviously, if work is continually added to the list each day, the project will never be done, because the stock will be at zero at the end of each day, but then tomorrow more work will come in.

So that, in essence, is burndown charting. If you’re not currently using it and have a large number of similar work items on your project (or sub-project) then it’s a useful technique to experiment with.

Book Review – Peopleware: Productive Projects and Teams

Similar to Rework, Peopleware focuses on the human side of project management, and specifically undoing many of the dysfunctions of organizations that make employees ineffective. Peopleware, as the name suggests is about how individuals can achieve flow and how team dynamics make projects successful and should be useful to most project managers given the provocative ideas that it contains.

The importance of efficient office design

Cost efficiency in office design favors crowding large numbers of people into ever smaller spaces, this increases noise and distractions making it harder for employees to be productive.  The costs of these interruptions then mean employees spend more time recovering from interruptions than getting meaningful work done offset the cost savings of spending less on office space. Because of the importance of this topic, the authors spend a lot of time discussing optimal workplace design.

Inefficient design of the telephone

The authors also point out that the telephone was poorly designed, rather than ringing once and then giving the receiver the choice to answer it rings incessantly until it is answered. The telephone, like the cramped office, promotes interruption. Interruption is the enemy of efficiency because it makes it hard for employees to be productive.

“Open kimono” management

In addition to office design, the book spends a lot of time on team dynamics, the importance of “open kimono” management, delegating and empowering employees and fostering communication and shared values within teams. “The managers’ function is not to make people work, but to make it possible for people to work.”

Overstaffing projects in the initial stages

Most directly relevant to project management, the authors argue that projects are often overstaffed during the planning phases for political reasons, planning and design requires small teams, whereas execution requires a much larger team. As the project requirements move from planning to execution, so the team size should increase. However, the authors seldom see this happen, arguing that most projects have excessively large teams during the design phase.

Despite the reference to projects and teams in the full title the book focuses more on management and team dynamics, and takes an adversarial tone against many norms of organizations. In this way, the book is very similar to Rework, and is more useful to the manager of people than of projects. The book is initially written to focus on the process of designing software, but most of the conclusions are broadly applicable.

The Myth of the Triple Constraint

At its heart, successful project management requires softer skills such as communication and persuasion. This why the few more mathematical elements that do exist within project management receive such attention, from estimation techniques to Gantt charting and the triple constraint. However, unfortunately the triple constraint is more of an optical illusion than an effective representation of the project management trade-offs.

Let’s start with cost. The triple constraint is inconsistent with Frederick Brooks’ insights. If you add money to a project, you are more likely than not going to have to add people. Those people will need training and expand the communication nexus across the project team exponentially. This additional training and communication will slow things down, at least in the short term.This is the opposite of what the triangle supposes. So you cannot seamlessly flex the budget to ensure you hit your project goals.

Next scope, the problem here is representing scope as a continuum, where you can chip away or incrementally add work items to the project to flex schedule and cost to the right values. This approach works until it doesn’t. Project success is often binary rather than a continuum. The iPhone 4’s reception problems or the Deepwater Horizon rig show that only up to a point can scope scale up and down before the project hits major risks. In fact, the baggage system at Denver Airport shows that the scope of some projects are infeasible regardless of cost or time.

That leaves schedule as the one corner of the project triangle that can legitimately flex, perhaps this accounts for why most projects finish late. The other corners of the triangle aren’t as malleable as they seem.