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.
September 22, 2009
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.
August 27, 2009
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.
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.
August 21, 2009
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.
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.
May 20, 2009
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:
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.
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
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!
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!
April 6, 2009
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:
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.
March 12, 2009
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
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
Subscribe to:
Posts (Atom)