Brief tip 3: Now, write that down

Even if you use lightweight methods, which can be an excellent choice, with less focus on documentation it does NOT mean that you abandon writing down conclusions from meetings, internal discussions or how a difficult project issue was agreed to be handled. My most basic, but maybe the most useful, tip is:

Be sure to put conclusions in writing immediately, even if not using documentation heavy methods

I find over and over in projects that same discussions will be repeated throughout the project because participants are unsure what was concluded. To settle a discussion can sometimes be hard and time consuming work. Then you ought to think that writing it down and sending it by email just “to confirm and summarize my understanding of the conclusion” would be easy and done at once? The next time, do it.

Writing down conclusions is equally useful for internal architectural discussions and for external commercial ones. This is also related to the previous point about expectations and mutual understanding. You have the chance to use the power of definition. Your customer or your team will even thank you for it most of the time. Writing things down to document decisions will help you tremendously delivering projects, agile or not – it is what consultants like to call quick wins or low-hanging fruits.

That was my tip #3. Now go pick those fruits. I look forward to read any comments – even if you don’t agree, or maybe particularly if that is the case.

Brief tip 2: Manage those expectations!

Excuse me for the use of the exclamation mark in the title. I promise not to do it again, but as this point was beaten to the #1 spot, I just had to do it. :-) I can’t say strongly enough how important I feel this is.

Let’s take a slightly academic approach. Let’s say that customer satisfaction relies primarily on:
1) What the customer expects
2) What you deliver in your project

Now, how long do you spend doing 1) and 2) during the whole life cycle of the project? Seriously, do think about it for a minute. I have found that it can sometimes be extreme. That holds true both on a project level, but also on the micro level – haven’t you sometimes spent hundreds of hours tweaking a feature that the customer didn’t actually find that important? Could you maybe just have negotiated that out, perhaps giving something more valuable with less work in return?

Typically I find that way too little time and effort is spent on managing expectations. One way to uncover misaligned expectations is to be explicit about what you are NOT planning to deliver or do. Expectation management is not an one-off in an early phase, but something that you continue to do at every chance all the way until the project is signed off. Thus I formulate my tip #2 as:

Be sure to use every chance throughout the project to manage expectations

The process of managing the expectations all the way through the project is not only to the benefit of the supplier. Another expression for managing the expectations could actually be to really understand the customer’s needs. So if it is more politically correct, feel free to change the title of the point to “ensure mutual understanding”…

You can talk about managing expectations internally as well (for instance for the team or line management if you are in a matrix organization environment), but I won’t do that here.

That was my tip #2. I look forward to read any comments – even if you don’t agree, or maybe particularly if that is the case.

Brief tip 1: Don’t forget the people

I promised to deliver the tips in a roughly prioritized order. Thus, I had to start with this one – especially since most of my other tips will be somewhat more focused towards the harder aspects of delivering successful projects. So tip number one is:

Do not forget that it is the people in the project teams that actually deliver successful projects

The softer skills, needed to foster a team environment everyone will enjoy, contribute to project success at least as much as methods, templates and processes do. Motivated and happy team members run in circles around their dissatisfied and demoralized cousins! They take responsibilities and grow in a self-reinforcing virtuous circle. When you have gained trust early on in the project, they start raising issues as early as they even begin to sense them, instead of just before they blow up on you all.

Often the role of the project manager will be more of a facilitator than a more traditional manager. Also, if you operate in an environment and/or framework that command traditional top-down thinking, getting the balance right with bottom-up empowerment is important.

You should not only cultivate your team internally. Remembering to take good care of people and show a behaviour that helps people feel valued are equally important when dealing with people outside the team, for instance the customer if you are a supplier. If you run intro trouble, and almost any project of a significant size will at some point during its lifecycle, it will be so much easier to settle and move on if you already have established a platform of trust and maybe even a type of friendship with the client at this point.

And by the way: Don't try faking it. You will get caught and nothing will destroy carefully earned trust faster. So you have to really love your job and care about your team...

That was my tip #1. I look forward to read any comments, but you will have a hard time arguing that people are not important – even if you can present hard facts or rankings to back them up (this is one of my top five favorite Dilbert strips of all time, taken from “The Dilbert Principle” book by Scott Adams):

Introducing the “Brief tip” series

I am today kicking of a series of posts, aiming at a total of maybe 10, containing practical tips for day-to-day work managing projects in general and software development projects in particular.

Some of the posts will include a specific tool, procedure or checklist, but most will be more general in nature. Hopefully they will all be thought-provoking. After all, I do not believe in any silver bullet procedure for ensuring top quality project management or software development. That being said, procedures and checklists can help a top quality project manager when used with thought. :-)

I will be writing the posts in a roughly prioritized order (meaning that I write a piece when I find the time and about a topic not yet covered!). I hope you will find them useful, and look forward to your comments even if you don’t agree, or maybe particularly if that is the case.

The missing link between management information and agile methods

It is now pretty much accepted, and to some degree starting to be confirmed by actual empirical data, that agile software development can lead to better bang-for-the-buck than the traditional requirements gathering -> analyze -> design -> develop -> test iterations with comprehensive documentation in each step of each iteration. The concept is rather simple: Do not spend time on details you are unsure will have value, and always make incremental improvements to a working product that you get up and running as quickly as you can.

Also, by involving the product owner directly in prioritizing product features, adapting to changing customer requirements will be built into the process. Another element of many of the agile methods is cross-functional and often self-managed teams that respond to a changing environment, rather than following a detailed plan. When you think of it, the conceptual leap from lean manufacturing as perfected by Toyota to agile software development is maybe not that large – at least not in underlying principles.

But, even if the customer’s senior management accepts the notion of increased value and efficiency through flexibility, they are often not willing to accept the notion of just developing in a broad direction to create as much valued functionality as possible until the money runs out. Some more structured planning and reporting is expected. So how do you handle this as a project manager? This is the topic of this post and I will not go any more into the details of agile methods as such here.

Often the solution chosen, if you cannot get the customer to choose an all agile approach (which I believe in practice often means a time and material type contract), will be a hybrid. Pragmatic as I am, this is an approach I have used in some of my projects. The problem is that this often results in a missing link between the software development process and the management information. This leads to the classical situation so often captured in the Dilbert cartoon, where engineers and management live in two distinct worlds with little communication coming across with the intended information still present…

This presents you as a project manager with two challenges:

• How to translate the legal obligations and high level plans into meaningful guiding for the day-to-day work for your developers, without falling back to a detailed pyramid of specifications and the team spending a too large part of its time producing documentation that will not be used
  
• How to translate the actual work done and progress made into a world with more structured plans with fixed milestones

These challenges are of course not new, but what makes them different than just a work breakdown type of task is that the details of what happens in the execution step is not planned upfront. It thus take a lot of skill to be able to agree the right high level milestones, so that they can be reached using agile methods for the actual execution. It really is a challenge to be as specific as necessary for the customer to be confident the value will be delivered as agreed, but not so specific that it kills the whole concept of agility upfront. In my view, this is maybe more an art than a science – so I am afraid I can provide no simple checklist to achieve that goal, but it helps to know that it is a challenge and think about it upfront.

And there is no reason to paint it all black. It is indeed possible to provide those missing links. For instance the burndown charts and list of completed issues of Scrum in the agile world provide excellent input for a Highlight Report in the structured planning world of PRINCE2. Similarly breaking down a PRINCE2 Stage Plan into a product (and later sprint) backlog of Scrum or a similar method can work just fine. However, there is of course tension between the different basic philosophies that you should discuss with your client. But as long as your client buys in to the idea that you actually deliver more and more relevant products, even if she might not be willing to let go of more traditional planning, I think that this hybrid model can work better than not trying to achieve any of the benefits of agile software development at all.

Agility as a more general term is certainly a key treat for a project manager to be successful. However, my take is that the toolkit of the agile software development movement often fall way short of covering what the customer needs to feel comfortable with her project. To avoid the situation with the missing link, the project manager must be comfortable operating in both worlds and tie them together in a coherent whole, while enjoying the trust of both the developers and the customer. Then the situation will hopefully not be exactly as Scott Adams sees it below:

I have heard some argue that the role of the project manager is obsolete when moving to agile/lightweight software development methods. I’d like to argue that it is more important than ever, but more demanding – as you have to be comfortable in a broader span of processes and skills than before. I will probably return to the role of the project manager and the mapping to roles in Scrum in a later post (should she be the scrummaster or the product owner do you think?).

Remember what Keynes once wrote: It is better to be roughly right, than precisely wrong. Agile methods are a way of achieving just that, but the direction you go must be managed along the way and senior level management may not want to adapt 100% to this new way of working. As the project manager, you thus have to be the translator and understand both worlds – in other words be, or at least provide, the missing link proposed by the title of this blog post.

Let me know what you think by leaving any comments you have below. As always, I hope to learn a lot from them.

Alignment of project dimensions: A balancing act

When writing the promised piece on agile methods and management information, I found that I wanted to present some thoughts about alignment of different dimensions of projects to avoid having to make the other article longer than necessary. Thus this post first.

I have found it useful to think about the alignment of some project dimensions before signing the contract and kicking off the project. The dimensions I will consider here are contractual terms (pricing), collaboration and strength of relationship, and the software development method to be used. Your selection of variables may vary, but I insist that trying to take such a bird’s eye view is useful when assessing the risk of project failure.

Below (click to see it in full size) is four actual projects placed in these dimensions. They are all software development projects, but differ somewhat in terms of complexity of integrations, amount of front end vs. back end programming, etc. as well as size. So they are by no means a perfect academic sample set, but they are projects that I know because I have worked and lived them.

As you might guess from the topic header, my hypothesis is that some combinations of the dimensions fit better together than others. Which of the projects above would you be afraid of taking on as project manager or team member? Which did you think get into trouble?

In retrospect, one of the possible “doomed to fail” projects actually didn’t (number 4). I try to cover the reason why in my next post. The other prime suspect, number 3, did actually fail spectacularly in terms of profitability. In fact, I took over this project midway (that is when just about 110% of the budget was used…) and even without drawing out the diagrams, the missing alignment was striking. However, the end product developed was to the customer’s satisfaction and new projects will be conducted that hopefully will be better business as well.

Another way of viewing the above dimensions could be in a 2x2 matrix (I am currently a consultant, after all!). Below I have tried to do that, with development method on the vertical axis and contract/pricing horizontally. The color (blue=”colder” customer/supplier relationship, red=strong partnership) of the dot indicates the form of collaboration, to avoid fiddling with three dimensions.

In danger of over-simplifying, I’d like to make the following remarks about these quadrants:

• The bottom left quadrant is just fine, although maybe a little bit old-fashioned. You could consider discussing with the client if a more flexible approach could be more suitable (moving up and right in the chart) and delivering more value.
• You should be extremely careful if you are in the upper left quadrant. You must then be absolutely sure that you and your client have found a good way to manage scope adjustments. I would also never conduct a project in this space if it is not a strong relationship with the client, i.e. a "red dot" above. Without these two in place, this is the “doomed to fail”-quadrant.
• The upper right quadrant if the place you probably want to be operating most of the time with agile methods. Especially with a strong relationship with your client (red dot). Be sure to manage expectations both upfront and at every increment, though. Often it doesn’t help to have the legal contract on your side if your most important client is not close to satisfied after all funds are burnt doing iterative improvements.
• The lower right quadrant is probably just fine, but it indicates that although there is client/supplier trust, indicated by the choice of time&material pricing, there is actually no belief in the gains promised by agile development methods. Thus, one gets the formal overhead without really needing it to handle pricing and legal issues. But formal specifications can absolutely be a way to handle the expectations management mentioned in the previous bullet point. Some target price regimes might fall into this quadrant, but not all (for example, project 4 was a target price regime).

Another related way of looking at this, is through the classical project management pyramid – TRQ, time, resources and quality/scope. The basic idea is that you cannot change one without adjusting the other accordingly. So if you fixate time and cost, certainly the details of scope can be a variable throughout the project. This view fits quite nicely with what DSDM preaches and on the development level this is the way I find working with Scrum-like approaches most fruitful.

Of course, my comments about the sample projects at this point are with the power of perfect hindsight. But let’s look again at project number 3, where we obviously tried to do flexible development with slim specifications with a completely new customer (collaboration form is not always a function of length of the relationship, but the two are usually strongly correlated and in this case it was a new customer) at a fixed price as if it was a classical waterfall approach we were using. Was it very likely to succeed if judged upfront? I think not.

Please do not read my comments only as a way for vendors to maximize their profits and minimize their risks. The assessments of the project dimensions should rather be discussed openly with the client before kicking off the project. It is after really understanding your customer’s need you will be able to make the best trade-offs for that particular case. Project management methods, and legal contracts for that matter, has large elements of tailoring after all.

There is a lot of fuzz about the specifics of each agile method proposed. Maybe too much. To me, agile software development is actually just as much about mindset and approach as it is about specific methods. And I do think that one should make sure that the mindset and the more formal frameworks (contract, form of collaboration and actual development methods being the three sampled here) match and discuss this upfront between customer and supplier.

In an earlier draft, I considered using project size as one of the variables. This could easily have been included for example through the size of the dots in the diagram notation. I considered about 10 projects I had managed myself and a few others that I know fairly well and I did not really see size (ranging from a few hundred to many thousand hours) being as important as the variables I have proposed above when considering if agile methods will be suited. But you might beg to differ? Let me know what you think by leaving any comments you have below. I hope to learn a lot from them.