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.