Those who can, do...

You have probably heard some variation over the saying: Those who can, do. Those who can't, teach. Those who can't teach, consult. I am actually going to complement my consulting by teaching the next semester, so I guess that puts me quite clearly in the "can't do quadrant"? :-)

Anyway: The subject I am going to teach is a 2nd year college course in computer science, focusing on XML and web technologies, at NITH in Oslo. The gig will be starting in January.

It might have been only a matter of time before I had to try this[1], with parents that are both teachers... Even so, it is only a thing I do a small portion of my time because I hope it will be energizing and meaningful. Or maybe it'll just be frustrating and make me feel old? I might post some of my experiences after the semester.

With the holiday season coming up I would also like to take the opportunity to wish you the best and suggest you make sure to really recharge those batteries that might be close to running out as everything must be finished in time for Christmas...

[1] - One might argue that I have tried a little bit already, as guest lecturing and training short courses is something I have done on the side both while I was a student myself and later.

Summarizing my brief tips for project managers

So, that was the 10 posts. Here are my 10 brief tips for successful project management summarized (each sentence links back to the individual post):

1. Do not forget that it is the people in the project teams that actually deliver successful projects
2. Be sure to use every chance throughout the project to manage expectations
3. Be sure to put conclusions in writing immediately, even if not using documentation heavy methods
4. You can never communicate too much as a project manager
5. Keep a close eye on risks throughout the project and use a visual risk log as a communication tool
6. Starting - not just planing, but actually doing - the most difficult tasks as early as possible increases the likelihood of a good result and minimizes the effect of a bad one
7. Establish checkpoints that you follow in each of your projects, even if operating in an agile way
8. As a project manager, try to add value beyond administering the project
9. Make sure that you have buy-in on all relevant levels, and reconfirm this as the project moves on
10. Try to look beyond the project, to ensure the project contributes to reaching the overall goals of the organization

When I look at it now, what do I feel – should I have changed something drastically? I think I might have created one specific post on goals. I think it is really important to have the goals clearly defined (and on the right level) and understood across project team and stakeholders. That is maybe buried a bit in the “managing expectations” heading in the current list of tips. Make sure to have it clearly visible in your mental checklist.

Apart from that and to be sure to communicate roles and responsibilities very clearly (and also to always work in stages or increments, but that is sort of given and an underlying assumption in everything that I have written so far, I think...) I am quite happy with the list as it has developed. But you might not be, and then the best way to show it would be leaving a comment. :-)

The always challenging question of summarizing it all in a sentence? Well, how about: Be proactive and care for your team, choose common sense rather than legal fights and have fun!?

Final brief tip, #10: Look beyond the project

I must admit that I love projects. I find them energizing and really enjoy going from the unavoidable feeling of uncertainty if it is feasible at all, to a successful delivery. I also like to be able to finish off, and then start a new one – with clean sheets (for the joy of Norwegian readers, I’d like to add a reference to Alf Prøysen, who came from a place close to my mother’s, at this point: “Du skal få en dag i mårå”, which I would say translates more or less to “You’ll have another chance tomorrow”).

Even if it you are like me and are happy about finishing off the project and then start a new one, possibly a different place and in a different field: I urge you to try to win the war, not only the battle… Thus my 10th and for now final tip is worded like this:

Try to look beyond the project, to ensure the project contributes to reaching the overall goals of the organization

You can be sure no-one will thank you for delivering on your formal mandate, if the product you delivered does not really leave behind anything valuable or useful when the project is terminated.

For me a key aspect of project management, as well as management in general, is to pursue continuous improvement, both within the project and across all projects of the company. The more mechanistic aspects of this, with Lessons Learned logs etc., are well covered in most project management methods. But it is of course even better if you can adjust course rapidly (agile, if you will…) as the project goes along, and that is as much a question of attitude as of hefty templates.

Another classical fight is the one between short terms requirements (“give me that functionality, and give it to me now!”) and long term demands of architecture and maybe even cleaning up some old mess. Again, trying to eat the elephant in smaller pieces is key – try to build architecture project by project and if you have a large code base (and they are never only pretty), leave it just that little bit better every day. Oh, and when estimating the cost of your next project: Make sure to estimate the required time and cost to improve architecture as you conduct the project.

I am considering writing a piece about project portfolio management, arguing that this is really more than what can be achieved in a project management office or similar structures. I hope to do this sometime before Christmas. Please come back to have a look. My next piece, though – and hopefully in just a few days, will be summarizing the brief tip series of posts.

Development in software business models – and the power of hindsight

When I recently was selecting a mail solution for my new company, I went for Google Apps. I did this after also considering a small business edition of Exchange, as well as just continuing to use the built in email service from my domain hosting provider that I already had up and running. Also my current client, i.e. my previous employer Inspera, has moved to Google Apps from an in-house Exchange solution, they just finished the transition last weekend.

These two decisions made me think back to what I wrote in my thesis on software business models in 2007 (part of my MTM degree, an MBA in technology management from NTNU, MIT Sloan and NHH - link to full foreword/abstract is provided for anyone interested):

…[even if] there is no “one size fits all” for business models in the software industry, if I had to place one bet on which business model innovation that will have most impact based on my findings, my decision would be clear: My money would be put on SaaS – on-demand subscription based software. Predicting paradigm shifts is a risky business, and especially so with shifts that have been predicted similarly without really happening before. Nevertheless, my take is that enough enabling factors have changed so even if it will not replace the traditional license, it may radically change the way software is sold, distributed and developed the coming years.

So the million dollar question is: Is this actually happening for mainstream applications for mainstream companies as we speak?

Extrapolating from the two samples (yep, two years since I last touched academia and reading the daily Dilbert since...) the conclusion has to be: “Sure”. On the other hand, I have also worked for some big companies over the last year that just wouldn't even start to consider Google Apps. But still, major changes in buying patterns often start with smaller companies and over time becomes an option also for the larger enterprises requiring time-tested and mature solutions.

Even if I feel the last two years have added support to my hypothesis of a possible “disruption from below” ala Christensen, I think the jury is still out on the question if SaaS will replace the traditional license based model as the dominant model at any point – or just be a supplement. (And to me financing a traditional license – making it look somewhat like a subscription – does not make it SaaS, by the way.) Cynics might also add that the predictions of net-PCs given in 1998 are not much different from the SaaS and “everything in the cloud” visions of today, they might argue that it has been coming in large scale “real soon now” for over ten years...

Reading the abstract two years after also drew my attention to another thing I wrote, that ...lines between data, applications, software and services can sometimes be blurry. This I at least think is even truer today than it was in 2007 – or to ask rhetorically: Is Twitter worth a zillion because of its software?

A twitter-er with no tweets...

Although I feel a certain degree of ambivalence towards the (near) real time aspect of Twitter, I have finally given in and registered - after one of my generally very insightful colleagues (a dedicated non-fan of Facebook, BTW) insisted it was very interesting and even useful.

I have no ambitions in the directions of real time updates of what I do (my life just isn't that interesting), but hope to take part in some interesting discussions.

My twitter ID is pmmonkey. Will probably keep my read-to-write ratio high going forward, but maybe time to post that virgin tweet now anyway...

PMMonkey goes entrepreneurial (again)

I have recently started my own company, Innovation Consulting - the formal registration went through last week after quite a bit of paperwork. My first project is helping setting up an offshore development centre for Norwegian software vendor Inspera (that I used for work for, as CTO and later VP of Consulting) and their partner in Romania.

I am not yet sure if this will be a temporary thing with only myself, or if I will hire other extraordinary people and try to make the company scale. What I do know is that I am available as part-time advisor if you have exciting and challenging projects in the first half of 2010 :-), as I have commited to the above mentioned project until August 2010.

Brief tip 9: Ensure buy-in and reconfirm along the way

Wow, a new post not that long after the previous. Another brief tip coming up, which is is simply going to be worded like this:

Make sure that you have buy-in on all relevant levels, and reconfirm this as the project moves on

The first part might be too self-evident, but make a mental note of the second part. It is in fact easy to forget this in the spur of the moment, and a project can often be nothing but a long sequence of hectic moments. Taking the time to involve key stakeholders, getting their opinions and buy-in (adjusting the course as required) will give you back the effort tenfold later – which may in turn contribute to more control of the hectic moments later in the project...

I think the tip is relevant on both a team level and an executive level. On the executive level, you might find yourself trying to mitigate different and conflicting interests. When this is not feasible, you hopefully have set up escalation mechanisms to get to a decision and move forward. This process also ties closely back to the second PM brief tip of managing expectations closely.

On a team level, reconfirming tasks, responsibilities and estimates are all important. This will also be a self-reinforcing loop, as team members tend to take on more responsibility when given the trust. Of course, you will have to work hard to create a context where the likelihood of succeeding give OK odds – if not the responsibility will be more like Scott Adams demonstrates for Dilbert as shown below:


I also think the principle of reconfirmation and no surprises can be used to contradict what some people seem to think about “that great final presentation of the project”: My take is that there is absolutely no point in such a “big bang" final presentation aimed at impressing and surprising the audience (often CxO-level). Share your thoughts (and software, if your project is developing any) early as much as possible, refine them along the way and deliver the final presentation knowing that the message will be understood.

Brief tip 8: Add value beyond administering

A little while since my last post. Looking back (wine, food and beaches in Tuscany and later Spain - then a surprise U2 concert as a birthday present from my wife), I can't say I got the priorities wrong. Good project management. :-) Anyway, here is another "brief tip":

As a project manager, try to add value beyond administering the project

The last year, I have completed my PRINCE2 Foundation and Practitioner certifications. In PRINCE2 there is a pretty clear advice that the role of the project manager “…is to manage, not to do”. While I see it as important that the project manager don’t loose her view of the big picture because of working on details, I actually think that it usually works better if the project manager can add some subject matter expertise or otherwise contribute beyond administering the project.

Some project managers have a technical background before being promoted to their own level of incompetence (the Dilbert Principle in all its beautiful essence). For these, taking part in architectural roles or detailed design may be a good way to be involved beyond the project administration. Others may contribute to testing, others again will have a strong hand on the business case and marketing plans.

I think you get some things for free if you as a project manager participate actively in the project (“doing”, if you will…). For instance if you take a role as a tester[2], you get project content and status under the skin “for free” that you would otherwise have actively worked to obtain.

For the team to see that the project manager is working along them (a Scrum master might very well be a developer for the most part of his time) can also be motivating and it shortens distances for communication and makes it easier for the project manager to detect problems early through informal channels.

[1] – PRINCE2 is a trademark of the Office of Government and Commerce in the UK and other countries

[2] – I do agree with PRINCE2 that the project manager should not be the same person as responsible for quality assurance though. If at all possible, it will make life easier for everyone knowing that there is two different persons filling those roles.

Brief tip 7: Choose your checkpoints

In my current job at PA, we have checkpoints, forms and procedures to ensure quality and avoid taking too much risk. That is all very fine if you have the machinery to handle that, as is the case with PA. But what if you don’t? I think you still need some sort of checkpoints (often commercially focused), even when you operate using agile methods.

I’d like to share with you what we ended up with when selecting some checkpoints for our projects at Inspera and hope you will find it useful. These are, more or less, the mandatory checkpoints we ended up with:

• Starting work on a proposal
• Delivering a proposal
• Project initiation/kick-off
• Periodical reporting of progress and budgets (here it was monthly, YMMV)
• Project sign-off, with a simple client satisfaction survey and handover to maintenance

What if you are not ready even for this level of formalism? If I should keep just two checkpoints, I think I’d go for proposal delivery (Who approves this in your company? Rules of thumbs for estimate breakdowns? Have cross-project coordination of resources been taken into account?) and of course sign-off. This would probably be in a very small environment where surveillance of risk and project status would be done rather hands on by the general manager anyway.

I guess one wording of this tip could be:

Establish checkpoints that you follow in each of your projects, even if operating in an agile way

“Even in an agile way” might sound strange, but while the almost automatic checkpoint built into many agile processes (such as the sprint review) can be combined with commercial ones, that does not happen automatically.

That was my tip #7, written at Bremen airport in Germany - traveling to Belgium this weekend with my wife who currently works in the Netherlands. If you don’t agree or have something to add, please leave a comment.

Contract templates as project placebo

There was recently an article in the Norwegian (and Norwegian language) publication Computerworld claiming that the legal framework, which was based on a template from the construction business, had helped making a large IT project successful. I wrote a response to this, together with colleague Jakob Markussen, that you can read here (Norwegian).

We put forward that project management techniques including risk management, well-defined processes, iterative development, and last but not least the collaboration and communication is more important than the legal framework template that is chosen for a project. After all, as any of us that have struggled with contracts know, the real work is in the appendices – and if you don’t have to revisit details of the contract to resolve conflicts, even better!

Brief tip 6: Do the hard things early

As I mentioned, agile methods have some built-in capability of reducing risk by having a working version early and improving it in increments. In my experience getting an early version up often uncovers miscommunication and can minimize the cost of this.

However, I have found, both using cousins of Scrum and occasionally also methods maybe best described as the evil twin of the waterfall process (!), that there is often a tendency to postpone the hard tasks that we do not know how to handle. Don’t.

In fact, I’d like to advice as my tip #6:

Starting - not just planing, but actually doing - the most difficult tasks as early as possible increases the likelihood of a good result and minimizes the effect of a bad one

Starting working on the hard tasks early has multiple advantages, which include:

• You learn more about the problem domain early on, often this helps finding the final solution even if it will not be finalized until a later iteration.
• Often the hardest tasks in a software development project involve complex integrations and multiple parties. Then it is often length of the calendar time that is required, with the hot potato being passed around, and not so much the number of hours worked that will help. Also the effect of adding more resource when already late has been questioned all the time since the seventies (“Mythical man month”, anyone?).
• Some times the hardest tasks are actually not possible (or at least not feasible) to solve. Finding the workaround or even scrapping the project or functionality early is so much better.

That was my tip #6. Please leave any comments below. My best wishes for the Easter also go out to everyone stumbling across my blog.

Brief tip 5: Use a visual risk log as a communication tool

Risk is most often defined as uncertainty of outcome (both PRINCE2 and PMBOK stress that both negative and positive impacts are considered risks). As a project manager you cannot always find appropriate actions to mitigate risks, but you should be sure to communicate your view of risks and their status.

One of the great things about agile methods is that they have a built-in capability of reducing risk by working in small increments. Nevertheless, risk management is sometimes overlooked by Scrum-masters and the like that was “born agile” that does not have the classical, old fashioned if you will, project pyramid theory under the skin. I actually think this is an area where the agile movement can be supplemented by methods from more traditional methods, such as PRINCE2 or PMBOK.

The steps in risk management are really quite straightforward: 1) Identify risks 2) Classify them 3) Select appropriate actions. I think it is important to separate risk identification and classification. If you don’t, the risk (pun intended) of prematurely ignoring a risk as already handled or not understanding its impact if happening it is too great. Risk classification will vary from project to project and organization to organization, but impact, probability and proximity (in time) will be safe bets as a starting point. Needless to say, the risk log should be a live document that you keep updated throughout the project – I would say that a weekly review is a minimum.

If you set up the format of your risk log, be it a formal risk log of your favourite project management method or a more informal overview you keep for yourself, in a practical way, you can automatically view the risks visually. I have found this to be a good tool for communicating the status of risks to project boards and the like. Below is a risk matrix for this blog post created by such a setup:


I have uploaded the excel sheet that I used to create the above graph. I hope you find it useful. As mentioned, I think the risk log and resulting matrix can be a great communication tool – even if the exact computation of impact and probability is not very sound mathematically. The idea is of course both to keep an overview, but also to move the risks down and to the left. But don’t let the matrix lull you into a false sense of control, of course.

That was my tip #5. If you don’t agree, please leave a comment. Oh and I almost forgot to formulate the actual tip, here goes:

Keep a close eye on risks throughout the project and use a visual risk log as a communication tool

Brief tip 4: Communicate early, communicate often

This tip is simply:

You can never communicate too much as a project manager

You should communicate clearly, often and repeat important messages even after you think everyone knows every little detail of it. They don’t. This is not because they are lazy or forget easily, it is just that most often they have not had the information internalized through lengthy discussions or working on the issue for a long time.

When the first members of the team smiles ironically when you repeat the message, you are not even half way through. When team starts to make jokes or even parodies of your most repeated messages, I would argue you are probably about three-quarters through getting a message out to everyone that will be sticky.

I also believe in sharing whatever information you have with the team early, even if you are still waiting for a conclusion of an external discussion. Even if one can argue that this can be confusing for the team sometimes, I feel it builds trust. Also, you avoid running into situations where you are unsure what you can say based on what you have said before. If you don’t do it, you will sometime have to make priorities that are hard to understand for the team. So I think saying “this is all that I currently know and I will share it now” is usually the best way of handling it.

This philosophy plays well with a notion of involving the team in decisions and to be able to make rapid adjustments of direction. You can formulate the principle of over-communication as a virtue the way I do in the title of this post: Communicate early, communicate often. As an added bonus, a little word play back to one of the principles of agile software development. :-)

That was my tip #4. If you don’t agree or would have ranked it differently, please leave a comment.

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.