tag:blogger.com,1999:blog-4836586006658383212023-11-16T19:16:38.996+01:00Team Based ConsultingThis blog is meant for senior managers who sponsor or run complex projects. the blog is intended to provide a ongoing update of issues related to complex projects.Rune Aresvikhttp://www.blogger.com/profile/10439422800800266511noreply@blogger.comBlogger43125tag:blogger.com,1999:blog-483658600665838321.post-44380977596076967032016-02-04T17:36:00.000+01:002016-02-04T17:36:17.762+01:00Back to consulting!!<span style="font-family: Arial, Helvetica, sans-serif;">Life moves in mysterious ways.</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">In the two previous blog entries I explained that I had stopped with consulting to focus on setting up a new healthcare business. That business was a huge success. In less than five years we put in place 50 small-scale locations for helping (young) people with autism, had 200 employees, and helped many people with autism reach their targets (finishing school, finishing university, finding and keeping a job, etc). I have now sold my shares in that company and have started the next chapter of my life.</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">My current focus is "Innovation in Healthcare" and I am doing this through a mixture of consulting to existing organisations and the development of new innovative healthcare organisations. My consulting work with existing healthcare organisations usually involves working closely with teams from the company and utilizes the same techniques as developed for Team Based Consulting. My team members therefore are linked to <a href="http://www.slideshare.net/RuneAresvik/the-third-way-running-effective-projects" target="_blank">my article</a> on how best to manage complex projects and to this blog.</span><br />
<span style="font-family: Arial, Helvetica, sans-serif;"><br /></span>
<span style="font-family: Arial, Helvetica, sans-serif;">If you want to know more about my current activities please go to <a href="http://www.vardetun.com/">www.vardetun.com</a>.</span><br />
<br />
<br />
<br />Rune Aresvikhttp://www.blogger.com/profile/10439422800800266511noreply@blogger.com0tag:blogger.com,1999:blog-483658600665838321.post-90434719745254164202012-11-01T10:54:00.000+01:002012-11-01T10:54:00.557+01:00Link to articleI had promised that my previous post would be my last; Sorry.<br />
<br />
As part of closing down my consulting business I have also decided to shut down the web-site for that business (mainly due to having to update to a new version of Joomla, but also due to overlap in the content of that site and this blog).<br />
<br />
One of the things that readers could do on that site was to download an article that I have written about how to best manage complex projects. This article can now be downloaded<a href="http://www.slideshare.net/RuneAresvik/the-third-way-running-effective-projects" target="_blank"> here.</a><br />
<br />
There is some overlap in the content of the article and the posts here in the blog. The article gives a structured overall view, and the blog-posts give more detail on specific issues. Read and combine as you see fit.<br />
<br />
<br />
<br />
<br />
<br />Rune Aresvikhttp://www.blogger.com/profile/10439422800800266511noreply@blogger.com0tag:blogger.com,1999:blog-483658600665838321.post-86295115446185415082012-03-08T19:13:00.000+01:002012-03-08T19:13:59.609+01:00Last and Final Update<span lang="EN-GB" style="color: black; font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-GB;">In December 1989 when I finished my MBA at INSEAD, my plan was to become a consultant for two years and then to get a Real Job. It has taken 23 years as a consultant, and I have had to develop a company myself, but I have finally reached this goal.</span><span style="color: black;"><o:p></o:p></span><br />
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-GB" style="color: black; font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-GB;">As of today, I am therefore stopping with my consulting activities. From now on I will be focusing all of my time on my role as Finance/Strategy Director for De Arvede Groep. De Arvede Groep provides long-term care solutions to specific segments of people with autism, and health-care services to small, alternative health-care providers. For the moment, De Arvede Groep is only active in The Netherlands, but we do see opportunities for expanding our services internationally. If you want to know more about what we do (and read Dutch) please go to the website of our current market propositions (<a href="http://www.stumass.nl/" target="_blank"><span style="color: blue;">Stumass</span></a>, <a href="http://www.capitowonen.nl/" target="_blank"><span style="color: blue;">Capito Wonen</span></a>, and <a href="http://www.arvedezorgdiensten.nl/" target="_blank"><span style="color: blue;">Arvede Zorgdiensten</span></a>).</span><span style="color: black;"><o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-GB" style="color: black; font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-GB;">I have greatly enjoyed my consulting career, both as part of larger organizations (LEK Consulting, PwC, and A.T. Kearney), and as a solo-practitioner these last five years. I have been privileged to work with great clients and great people. I know that there will be moments when I will regret my decision to stop. However, the health-care sector is going through a period of transformative change, and the opportunity to play a key role in building a company that will improve the lives of clients by offering better and cheaper services is irresistible.</span><span style="color: black;"><o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-GB" style="color: black; font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-GB;">As part of this process, I have also decided to stop adding new updates to this blog. For those of you who have been regular readers - I hope that you have enjoyed the posts and that they have neabled you to make your teams more effective. For new readers - I think that there is a lot of information in the updates that can help you make your teams more effective. </span></div><div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-GB" style="color: black; font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-GB;">I wish all of you the best going forward.</span></div>Rune Aresvikhttp://www.blogger.com/profile/10439422800800266511noreply@blogger.com0tag:blogger.com,1999:blog-483658600665838321.post-67626971086835832972011-10-26T20:51:00.000+02:002011-10-26T20:51:51.371+02:00Seven simple rules leading to successful Steering Committees<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgtbBd8NzLP7-urtJjzEprk6M1LJ2k-tvty7cg_bi6ayAEcyVOfoGW-CJNleLERc7_Yj_8SssA_MGEdxkFRqDRUDgj-ZI5SsVPh4RbN547Vrqhyn1yDUhI4FV3RpdKzfumuv3A5vfSanvRk/s1600/2011+-+10+Seven+rules+for+a+successful+Steering+Committee.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="192" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgtbBd8NzLP7-urtJjzEprk6M1LJ2k-tvty7cg_bi6ayAEcyVOfoGW-CJNleLERc7_Yj_8SssA_MGEdxkFRqDRUDgj-ZI5SsVPh4RbN547Vrqhyn1yDUhI4FV3RpdKzfumuv3A5vfSanvRk/s400/2011+-+10+Seven+rules+for+a+successful+Steering+Committee.jpg" width="400" /></a></div><br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt 2.25pt;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">In my previous blog-spot I presented my views on <span style="color: red;"><a href="http://teambasedconsulting.blogspot.com/2011/09/how-to-use-steering-committee.html">how to put together the optimal Steering Committee</a></span> (SteerCo). The main message was that very many SteerCos are put together for the wrong reasons and with the wrong participants. The only valid reason for having a SteerCo is if there is an ongoing stream of "steering" (usually a combination of decision-making on complex, company-broad issues and quality control from a company-broad perspective) throughout the project (and not only at the end). The participants should be chosen with these goals in mind, and should be the lowest-ranking people that can make the decisions that are needed.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt 2.25pt;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">Assuming that you have put together the optimal SteerCo, the next question is how you can make best use of it during the project itself (how to deal with the SteerCo at the end of project will be the subject of a separate blog-spot). The following rules will help you make the most of your SteerCo meetings:<o:p></o:p></span></div><br />
<div class="MsoListParagraphCxSpFirst" style="margin: 0cm 0cm 0pt 38.25pt; mso-add-space: auto; mso-list: l0 level1 lfo1; text-indent: -18pt;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US; mso-fareast-font-family: Arial;"><span style="mso-list: Ignore;">1.<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">Inform the participants at the start of the project about what you want from them. This may have been done as part of the process leading to the choice of SteerCo members, but is still worthwhile doing again. In an individual face-to-face meeting (before the first official SteerCo meeting) explain to each member of the SteerCo about the project, the role of the SteerCo, and why the individual has been requested / chosen to sit in the SteerCo<o:p></o:p></span></div><br />
<div class="MsoListParagraphCxSpMiddle" style="margin: 0cm 0cm 0pt 38.25pt; mso-add-space: auto; mso-list: l0 level1 lfo1; text-indent: -18pt;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US; mso-fareast-font-family: Arial;"><span style="mso-list: Ignore;">2.<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">Plan and schedule regular SteerCo meetings (and meeting rooms). Most people have very busy diaries and it can be very difficult to schedule a meeting involving several key managers. The best solution is therefore to schedule all expected SteerCo meetings already at the start of the project. Where possible, these meetings should be linked to key milestones and expected issues where input from the SteerCo will be needed. Sometimes it makes more sense to plan regular meetings (monthly/bi-weekly/weekly depending on the heartbeat of the project and the number of expected issues that the SteerCo will need to deal with). When scheduling these meetings, promise that you will cancel them if the meeting is not required.<o:p></o:p></span></div><br />
<div class="MsoListParagraphCxSpMiddle" style="margin: 0cm 0cm 0pt 38.25pt; mso-add-space: auto; mso-list: l0 level1 lfo1; text-indent: -18pt;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US; mso-fareast-font-family: Arial;"><span style="mso-list: Ignore;">3.<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">Plan each meeting well in advance. Find out if you have issues/decisions that need SteerCo attention. If this is not the case, then cancel the meeting. This will save you and the project considerable time, and will give you goodwill from your SteerCo members. The agenda and key issues to be discussed should be communicated to the SteerCo as early as possible so that they can prepare. In some companies where I have worked, there has been a requirement to send out the presentation to be used in the meeting. This has never been my preference, as it tends to lead to disjointed and unstructured discussions in the meeting itself. However, if this is the culture, then you do not have a choice.<o:p></o:p></span></div><br />
<div class="MsoListParagraphCxSpMiddle" style="margin: 0cm 0cm 0pt 38.25pt; mso-add-space: auto; mso-list: l0 level1 lfo1; text-indent: -18pt;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US; mso-fareast-font-family: Arial;"><span style="mso-list: Ignore;">4.<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">Make sure that the meeting room is available and that all the technical stuff (PC, beamer, etc) works. This is a bit of a "no-brainer", but, believe me; I have experienced all of this happening.<o:p></o:p></span></div><br />
<div class="MsoListParagraphCxSpMiddle" style="margin: 0cm 0cm 0pt 38.25pt; mso-add-space: auto; mso-list: l0 level1 lfo1; text-indent: -18pt;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US; mso-fareast-font-family: Arial;"><span style="mso-list: Ignore;">5.<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">Start the meeting by presenting the agenda and agreeing the planning and time allocation (especially important if one or more people need to leave early).<o:p></o:p></span></div><br />
<div class="MsoListParagraphCxSpMiddle" style="margin: 0cm 0cm 0pt 38.25pt; mso-add-space: auto; mso-list: l0 level1 lfo1; text-indent: -18pt;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US; mso-fareast-font-family: Arial;"><span style="mso-list: Ignore;">6.<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">Present your material in a structured and clear manner, and clearly specify what the issue/problem is, what the alternatives are, and what decision you are requesting. Make sure that a decision is given. If the SteerCo is not able to give a decision, agree what concrete steps need to be taken in order for a decision to be made<o:p></o:p></span></div><br />
<div class="MsoListParagraphCxSpLast" style="margin: 0cm 0cm 10pt 38.25pt; mso-add-space: auto; mso-list: l0 level1 lfo1; text-indent: -18pt;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US; mso-fareast-font-family: Arial;"><span style="mso-list: Ignore;">7.<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">Send out minutes of the meeting as quickly as possible (the next day at the latest). The minutes should be as short as possible, and if you can agree and use a standard structure, so much the better. The content should be limited to key decisions and a log of agreed action points. The minutes are extremely important as they provide a written record of decisions made, thereby ensuring that everybody has the same recollection of these decisions. The action log gives a written overview of the agreed "to-do's". This helps you and project team remember what needs to be done, and can also help in pushing SteerCo members to carry out activities given to them<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">If you have put together an optimal SteerCo and follow these fairly simple rules, then your SteerCo should play a valuable role in your project. Unfortunately, there are still a number of things that can go wrong. These will be discussed in a later update.<o:p></o:p></span></div>Rune Aresvikhttp://www.blogger.com/profile/10439422800800266511noreply@blogger.com0tag:blogger.com,1999:blog-483658600665838321.post-8645159903599644002011-09-20T11:50:00.001+02:002011-10-26T20:54:50.609+02:00Avoid usual mistakes in setting up your Steering Committee<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj1cRTUoH6yfJnPu1qMVPjCB5NRpWjKBEL65wEIMtKJ3KC0AemH-2aKDhFnZlxm3lY-rveIc5yVOjwD97aS9gSUfzdQQqmsQ_4I1FhdEGzQvZ1GfwNhrLgibbzSoUzM_bwAgTmMIpck96pf/s1600/11-How+to+use+a+Steering+Committee.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="183" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj1cRTUoH6yfJnPu1qMVPjCB5NRpWjKBEL65wEIMtKJ3KC0AemH-2aKDhFnZlxm3lY-rveIc5yVOjwD97aS9gSUfzdQQqmsQ_4I1FhdEGzQvZ1GfwNhrLgibbzSoUzM_bwAgTmMIpck96pf/s400/11-How+to+use+a+Steering+Committee.jpg" width="400" /></a></div><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">Last week I had an interesting discussion at a project I am working with for a leading European energy company. The project involves the development of strategic tool for the company's smart grid roll-out, and is key part of the future development of the company. The project manager felt that the Steering Committee that had been set up for the project was not providing him with any value and was taking away valuable time from him and other key project members. This was an interesting statement, as I had been told that many members of the SteerCo were also unhappy. Their complaints were centered round the reasons for their participation, the information they were provided, and the structure of the meetings themselves.<o:p></o:p></span><br />
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt 2.25pt;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">This got me thinking about steering committees and how these should be set up and used optimally. In this blog-spot I will focus on how an optimal steering committee should be set up. In later blog-spots I will talk about <a href="http://teambasedconsulting.blogspot.com/2011/10/seven-simple-rules-leading-to.html">how to best use a SteerCo during the project i</a>tself and how a project can ensure that its goals are met through the SteerCo.<o:p></o:p></span></div><br />
<div align="center" class="MsoNormal" style="margin: 0cm 0cm 10pt 2.25pt; text-align: center;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">------------------------------------------------------------------<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt 2.25pt;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">My assumption is that you are the sponsor or the project manager of a <span style="color: red;"><a href="http://teambasedconsulting.blogspot.com/2011/06/when-should-you-worry-about-your.html">complex project</a></span> and are in the process of setting it up. This means that you have carried out all the other steps required for a <span style="color: red;"><a href="http://teambasedconsulting.blogspot.com/2011/08/how-to-ensure-successful-start-up-of.html">successful start-up of a complex project</a></span> ( you have a well-structured understanding of the reasons why the project is required, you have defined clear goals and deliverables, you have set up a structured approach that includes key activities, dependencies, and milestones, and you have formed the best <span style="mso-spacerun: yes;"> </span>(available) team for carrying out the project. <o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt 2.25pt;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">You are now in a situation where you believe that you need to set up the Steering Committee. Either because somebody has told you to do so, or because you believe that "all" projects have such an entity. However, you also have some doubts as you do not really have a good idea what the role of the Steering Committee will be or who you should put in it.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt 2.25pt;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">I have seen very many situations where a project either has a SteerCo that is too big or consists of too senior people (misuse of resources). Projects run by external consultants often have this, as for them having a Steering Committee consisting of many senior executives is an excellent marketing tool. I have also seen many projects that either did not really need a SteerCo or had a SteerCo with the wrong participants. Thinking carefully about your SteerCo is therefore well worth your time.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt 2.25pt;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">The first step in this process is to get a clear understanding of why you want a SteerCo. Essentially there are four reasons for a complex project to have a SteerCo (sometimes overlapping):<o:p></o:p></span></div><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US; mso-fareast-font-family: Arial;"><span style="mso-list: Ignore;">1.<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">Decision-making - The SteerCo accepts the final results of the project, makes go/no go decisions for the implementation of project recommendations, and makes decisions during the project that are relevant for the overall direction that the project takes<o:p></o:p></span><br />
<span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US; mso-fareast-font-family: Arial;"><span style="mso-list: Ignore;">2.<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">Ensuring support - The SteerCo is used to organize staff for the project, to provide ad-hoc access to staff in the organization and to get buy-in for the final results of the project<o:p></o:p></span><br />
<span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US; mso-fareast-font-family: Arial;"><span style="mso-list: Ignore;">3.<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">Provide knowledge - The SteerCo is intended to primarily provide knowledge and experience to the project-team<o:p></o:p></span><br />
<span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US; mso-fareast-font-family: Arial;"><span style="mso-list: Ignore;">4.<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">Control quality and progress - The SteerCo </span><span lang="EN" style="color: black; font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN;">is a group of people ensuring that everything's OK with the project at a higher level than the Project Manager<br style="mso-special-character: line-break;" /> <br style="mso-special-character: line-break;" /> </span><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">You should also keep in mind that a SteerCo is often not the only solution that will help you deal with your needs. In my experience, the need to have a Steering Committee to make decisions is very often over-rated. If the only decision that needs to be made is at the end, then seeing the management team once at the end of the project can be sufficient. Only if there is an ongoing stream of relative complex decisions to be made, do you need a traditional Steering Committee that meets regularly during the whole project. Any smaller / less complex decisions can be made by the sponsor of the project.<o:p></o:p></span><br />
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">The idea that having a Steering Committee will ensure support for the project is based on an assumption that being the SteerCo will result in key people having more knowledge of the project, and that they will be "invested"<span style="mso-spacerun: yes;"> </span>in the process and conclusions developed by the project. Hopefully this then translates into help getting access to staff and buy-in for the results of the project. A key point to keep in mind is that finding staff is an activity that only takes place at the start of the project, and can therefore not be a reason for keeping an ongoing SteerCo. Buy-in for the need for a project and its conclusions and recommendations can also be created (often better and with less use of resources) through a series of one-to-one meetings with key managers.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">I have often seen a SteerCo be used to provide knowledge to the project team. If this is the only reason for having a SteerCo I would recommend alternatives such as an expert group or <span style="color: red;"><a href="http://teambasedconsulting.blogspot.com/2009/11/has-your-project-team-considered-all.html">Blue Teams</a></span>. This enables the project team to make direct use of the real experts instead of management, and also reduces the likelihood that they persons involved will believe that they need to make decisions (which is usually not the case).<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">The final reason for having a SteerCo is often quality control. This is based on an assumption that the project manager and sponsor cannot do this themselves, and that it requires more senior executives with a broader view of what is key for the overall company. This can be a valid reason if the project is very complex and "steering" is required based on a broad overview of the company. In my experience, the type of discussions that take place in this type of SteerCos is very similar to the SteerCos making decisions<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">Based on this overview you can conclude that a Steering Committee is only required when a project required senior-level "steering" as an ongoing process during the project. The "steering" provided in these situations can be seen as a mixture of "quality-control" and ongoing decision-making. All other reasons for having a SteerCo can usually be provided by other means that place lower time-demands on both executives as well as project-team members.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">The final question is then who you should put in your SteerCo. The first rule is to keep the group as small as possible (less use of resources, easier logistics for planning meetings, easier discussions, etc). The second rule is to find the lowest-ranking people that can make the decisions that are needed. A rule of thumb that has served me well is to discuss participation high in the organization, and clearly present the type of decisions that are likely to be made. The senior executive can then chose the person that he/she feels comfortable allowing to take the relevant decisions.<o:p></o:p></span></div>Rune Aresvikhttp://www.blogger.com/profile/10439422800800266511noreply@blogger.com0tag:blogger.com,1999:blog-483658600665838321.post-32513945984372280502011-08-29T12:16:00.000+02:002011-08-29T12:16:29.999+02:00How to ensure successful start-up of a project<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEibJ1fI7P5SD0IFQpNjgF92Ad4y-rH13jz10mTmudESuaa4Ctk06X05vAhgtOl7EaygjRDVdbPzF7dOvE1SGC9DEWuD0tYjrAvC-eTb-v8V-d9c1oOboE1KFOSLaoglgpmeD1oVgFEtTe8P/s1600/2011-8How+to+ensure+succesful+start-up+of+a+project.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="196" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEibJ1fI7P5SD0IFQpNjgF92Ad4y-rH13jz10mTmudESuaa4Ctk06X05vAhgtOl7EaygjRDVdbPzF7dOvE1SGC9DEWuD0tYjrAvC-eTb-v8V-d9c1oOboE1KFOSLaoglgpmeD1oVgFEtTe8P/s400/2011-8How+to+ensure+succesful+start-up+of+a+project.jpg" width="400" /></a></div><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">For most of us the summer is over, and we are back to work. For many of you this will mean starting up new projects. In a <a href="http://teambasedconsulting.blogspot.com/2011/06/when-should-you-not-use-consultants.html">previous blog-spot</a> I talked about which projects you should do in-house (i.e. not hire in external consultants). I will assume that you have a number of this type of projects under consideration and that your role is either being the sponsor or the project manager. <o:p></o:p></span><br />
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt 2.25pt;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">In my experience, the start-up is the most crucial phase of a complex project. This is due to it very much determining the success of the project, and the difficulties in to correcting many of the mistakes that are often made in this phase. <span style="mso-spacerun: yes;"> </span>Many times when I am called in to help projects that are ongoing but are facing difficulties, I have to re-start the project in order to get them on the right track again. <o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt 2.25pt;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">The main goal of the start-up phase of a project is to ensure that the project is defined optimally and clearly. If this is difficult, as it often is for complex projects, then a solution can be to do a scoping project that has the goal of developing a clear understanding of the problem at hand. Examples of such scoping exercises that I have carried out include a project that had as the goal to understand why delivery times were so long for a telecom company. The projects gave a number of clear issues leading to long lead times, and solving these issues then became a number of structured and focused follow-up projects. <o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt 2.25pt;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">Ensuring that a project gets a flying start entails carrying out a structured process that requires careful thinking at each step. The order suggested in the process is crucial, as each previous step provides key information and starting points for the next step. <span style="mso-spacerun: yes;"> </span>The steps that you as the project sponsor / project leader need to take to ensure that the project gets an optimal start are:<o:p></o:p></span></div><span lang="EN-US" style="font-family: Symbol; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">Clearly define the background for the project<o:p></o:p></span><br />
<span lang="EN-US" style="font-family: Symbol; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">Develop a clear goal for the project and translate this into structured deliverables<o:p></o:p></span><br />
<span lang="EN-US" style="font-family: Symbol; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">Clearly state the scope of the project<o:p></o:p></span><br />
<span lang="EN-US" style="font-family: Symbol; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">Decide the approach that the project needs to take<o:p></o:p></span><br />
<span lang="EN-US" style="font-family: Symbol; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">Find the staff required for carrying out the project <o:p></o:p></span><br />
<br />
<div align="center" class="MsoNormal" style="margin: 0cm 0cm 10pt; text-align: center;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">--------------------------------------------------<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">I am constantly amazed at the projects I see where the team members cannot clearly articulate why the project is being carried out. In my experience this often means that the team members also do not truly understand the work that they are carrying out, and are therefore very likely to spend time on wrong activities, or develop inappropriate conclusions from the work that they have carried out. The first step you need to take is therefore to clearly articulate the "why" of the project. This should position the issue in the broader context of the organization (strategy, etc), and ideally give a "burning platform" that will motivate team members, sponsors, etc.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">A clearly stated "why" for a project makes it relatively easy to develop the goal of the project. <span style="mso-spacerun: yes;"> </span>The goal of the project should be a clear and concise statement of purpose. It establishes what the project will do. Examples of goals in recent projects that I have carried out include:<o:p></o:p></span></div><span lang="EN-US" style="font-family: Symbol; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">Make the company profitable<o:p></o:p></span><br />
<span lang="EN-US" style="font-family: Symbol; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">Develop a clear telecom strategy <o:p></o:p></span><br />
<span lang="EN-US" style="font-family: Symbol; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">Develop a strategy for positioning the company in the New Energy market<o:p></o:p></span><br />
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">The goal is a fairly broad statement that says what the project will do, and is used to set expectations and establish a stake in the ground regarding what the project will do and the scope of the project. A common mistake is to state a goal that can only be reached far in the future with input from this project and other projects. This is not helpful, and effort needs to be made to ensure that the goal is relevant for the project at hand.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">The deliverables of the project are the concrete things that the project will provide. This should always be a noun, and be something that did not already exist. It can cover a broad range of "things" ranging from insight, a plan, an implemented plan, etc. The deliverables can be seen as how the goals of the project will be met. The agreed deliverables of a <a href="http://teambasedconsulting.blogspot.com/2011/04/use-project-team-to-plan-turn-around.html">recent turn-around project</a> I carried out included a) clear understanding of why the company was losing money, b) concrete actions to turn the company around, c) a new organization structure, and d) a focused and structured plan for the implementation phase. <o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">I have seen very many projects that have <a href="http://teambasedconsulting.blogspot.com/2009/11/ensure-that-projects-finish-on-time-by.html">gone wrong because the scope was not clearly defined</a>. Typical problems have included projects that have gone off on tangents that were not really relevant and projects that have been drowned in "extra" activities from sponsors and other stakeholders. While goals and deliverables clearly state what a project will do, a clear scoping statement states what the project will not do. This helps the project set and exceed expectations. In the cost-reduction project mentioned in the previous paragraph a clear <span style="mso-spacerun: yes;"> </span>scoping statement was that the team would not define detailed work-plans for the initiatives that it defined. This enables the team to push back on requests to do this work, and deliver the results within the agreed time-frame.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">Based on the deliverables and the scope the next step is to define the approach. I have seen many projects lose valuable time discussing the overall approach when this could and should have been done before the kick-off. Essentially the approach is defining how the deliverables will be produced and includes an overview of key activities to be carried out, key milestones, inter-dependencies between activities, etc. The best way to develop an approach is to start with the deliverables on the left-hand side of a page and work your way backwards.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">The final step in preparing a project is to decide on the required resources and staffing. The starting point for this exercise is the overall approach defined in the previous step. The key things that need to be decided is the total amount of resources required (how many for how long), and the specific types of skills and capabilities needed to make the project a success. Skills and capabilities can be divided into three main types:<o:p></o:p></span></div><span lang="EN-US" style="font-family: Symbol; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">Problem-solving skills<o:p></o:p></span><br />
<span lang="EN-US" style="font-family: Symbol; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">Technical / functional skills<o:p></o:p></span><br />
<span lang="EN-US" style="font-family: Symbol; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US; mso-bidi-font-family: Symbol; mso-fareast-font-family: Symbol;"><span style="mso-list: Ignore;">·<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">Interpersonal skills<o:p></o:p></span><br />
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">The challenge is to find the people who have the right skills and who are available. Availability is always a problem, and a tip is not to be too critical, as skills can often be developed during the project.<o:p></o:p></span></div><br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">Once you have gone through all of these steps, the time has come to start the project with a kick-off for the whole team. Based on the work that has been carried out in this phase developing a successful kick-off meeting is easy. The kick-off meeting will then provide the starting point for a successful project that will result in the agreed deliverables within the agreed time-frame.<o:p></o:p></span></div>Rune Aresvikhttp://www.blogger.com/profile/10439422800800266511noreply@blogger.com0tag:blogger.com,1999:blog-483658600665838321.post-66164458114865271292011-06-30T17:31:00.000+02:002011-06-30T17:31:34.281+02:00When should you worry about your internal projects?<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi1ws8KRhR0gZ9E2uxDDr394OV1z7GUJHBphCDFxy1AdGNq-vvXPobAPWuK0sCqOOAxmXsj4fYzWfmsynwMoH1JO9PW8Xg8uGgGmrxs0OYqiHC3P2dJM00NVp61XRGhuFq5aE9k1QLjNlJS/s1600/Wordle+-+When+should+you+worry+about+your+internal+project.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="232" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi1ws8KRhR0gZ9E2uxDDr394OV1z7GUJHBphCDFxy1AdGNq-vvXPobAPWuK0sCqOOAxmXsj4fYzWfmsynwMoH1JO9PW8Xg8uGgGmrxs0OYqiHC3P2dJM00NVp61XRGhuFq5aE9k1QLjNlJS/s400/Wordle+-+When+should+you+worry+about+your+internal+project.jpg" width="400" /></a></div><br />
<span style="mso-bookmark: OLE_LINK2;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">Many of you are in a situation where the number of complex issues that need to be dealt with outside of the standard organizational structures is growing. For different reasons, some economic and some related to a wish to build up internal capabilities, less projects are being outsourced to external consultants. Due to this, the number of internal teams dealing with complex projects is growing dramatically.<o:p></o:p></span></span><br />
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span style="mso-bookmark: OLE_LINK1;"><span style="mso-bookmark: OLE_LINK2;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">If you have a portfolio of complex projects then there are almost certainly one or more projects within the portfolio where you have a “gut feeling” that the project is not going well. Since you do not have any conclusive evidence it is difficult to do anything but to hope the best and see what the teams come up with.<o:p></o:p></span></span></span></div><span style="mso-bookmark: OLE_LINK1;"><span style="mso-bookmark: OLE_LINK2;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">Based on my experience, I believe that there are eight warning signals for projects that are not going well. The more warning signals that apply, the more urgent it is to intervene. The eight warning signals are:<o:p></o:p></span></span></span><br />
<br />
<div class="MsoListParagraphCxSpFirst" style="margin: 0cm 0cm 0pt 36pt; mso-list: l0 level1 lfo1; text-indent: -18pt;"><span style="mso-bookmark: OLE_LINK1;"><span style="mso-bookmark: OLE_LINK2;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US; mso-fareast-font-family: Arial;"><span style="mso-list: Ignore;">1.<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">The project-team appears to be dealing with a very broad range of issues</span></span></span></div><div class="MsoListParagraphCxSpMiddle" style="margin: 0cm 0cm 0pt 36pt; mso-list: l0 level1 lfo1; text-indent: -18pt;"><span style="mso-bookmark: OLE_LINK1;"><span style="mso-bookmark: OLE_LINK2;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US; mso-fareast-font-family: Arial;"><span style="mso-list: Ignore;">2.<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">The project team does not seem to be spending much time together</span></span></span></div><div class="MsoListParagraphCxSpMiddle" style="margin: 0cm 0cm 0pt 36pt; mso-list: l0 level1 lfo1; text-indent: -18pt;"><span style="mso-bookmark: OLE_LINK1;"><span style="mso-bookmark: OLE_LINK2;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US; mso-fareast-font-family: Arial;"><span style="mso-list: Ignore;">3.<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">The team is spending a lot of time carrying out “interviews”</span></span></span></div><div class="MsoListParagraphCxSpMiddle" style="margin: 0cm 0cm 0pt 36pt; mso-list: l0 level1 lfo1; text-indent: -18pt;"><span style="mso-bookmark: OLE_LINK1;"><span style="mso-bookmark: OLE_LINK2;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US; mso-fareast-font-family: Arial;"><span style="mso-list: Ignore;">4.<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">The team does not appear to be doing any meaningful analytics</span></span></span></div><div class="MsoListParagraphCxSpMiddle" style="margin: 0cm 0cm 0pt 36pt; mso-list: l0 level1 lfo1; text-indent: -18pt;"><span style="mso-bookmark: OLE_LINK1;"><span style="mso-bookmark: OLE_LINK2;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US; mso-fareast-font-family: Arial;"><span style="mso-list: Ignore;">5.<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">The team has very limited interaction with you(and other sponsors )</span></span></span></div><div class="MsoListParagraphCxSpMiddle" style="margin: 0cm 0cm 0pt 36pt; mso-list: l0 level1 lfo1; text-indent: -18pt;"><span style="mso-bookmark: OLE_LINK1;"><span style="mso-bookmark: OLE_LINK2;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US; mso-fareast-font-family: Arial;"><span style="mso-list: Ignore;">6.<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">Key stake-holders, who's by-in will be required for the project to be a success, are not aware of the project</span></span></span></div><div class="MsoListParagraphCxSpMiddle" style="margin: 0cm 0cm 0pt 36pt; mso-list: l0 level1 lfo1; text-indent: -18pt;"><span style="mso-bookmark: OLE_LINK1;"><span style="mso-bookmark: OLE_LINK2;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US; mso-fareast-font-family: Arial;"><span style="mso-list: Ignore;">7.<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">The project is not meeting agreed deadlines</span></span></span></div><div class="MsoListParagraphCxSpMiddle" style="margin: 0cm 0cm 0pt 36pt; mso-list: l0 level1 lfo1; text-indent: -18pt;"><span style="mso-bookmark: OLE_LINK1;"><span style="mso-bookmark: OLE_LINK2;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US; mso-fareast-font-family: Arial;"><span style="mso-list: Ignore;">8.<span style="font-size-adjust: none; font-stretch: normal; font: 7pt/normal "Times New Roman";"> </span></span></span><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">It is difficult to pin the team down on any meaningful conclusions<o:p></o:p></span></span></span></div><br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><span style="mso-bookmark: OLE_LINK1;"><span style="mso-bookmark: OLE_LINK2;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">Dealing with a broad range of issues is a danger signal as it very often means that the project is too broadly scoped to deliver concrete results and/or the team will need to carry out more work that is feasible within the agreed deadlines. The required action is to carefully consider what the project needs to deliver and ruthlessly reduce any activities that do not directly lead to this result. <a href="http://teambasedconsulting.blogspot.com/2009/07/how-to-help-project-that-is-dealing.html">See an earlier blog spot for more detail how to deal with this issue</a>.<o:p></o:p></span></span></span></div><span style="mso-bookmark: OLE_LINK1;"><span style="mso-bookmark: OLE_LINK2;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">If the project team is not spending much time together it either means that they are not spending enough time on the project, or that they are working alone. In my experience achieving strong conclusions and recommendations requires bouncing ideas off each other, combining insights, and jointly developing an understanding of the most appropriate conclusions and recommendations. The best way to deal with this is to ask the team why they are not spending time together, and "gently" push them to do so. <a href="http://teambasedconsulting.blogspot.com/2009/07/how-to-deal-with-project-team-that-is.html">See an earlier blog spot for more detail how to deal with this issue.<o:p></o:p></a></span></span></span><br />
<br />
<span style="mso-bookmark: OLE_LINK1;"><span style="mso-bookmark: OLE_LINK2;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">Interviews are often an integral part of the work required to carry out a complex project. However, I have often seen teams that spend too much time talking to other people (within the organization or externally) without having a clear goal for what they want to get out of the interviews, without writing up the results of the interviews in a structured manner, and without getting any data or support for key assumptions from the meetings. Often, carrying out interviews is a way of looking busy and not having to do any "hard" work related to developing conclusions. My recommendation is to suggest that the team develops an overview of all the interviews they have carried out and what has come out of them. If the team has a program of interviews planned, ask them to provide a structured overview of what is the expected outcome / value added of each interview. Based on this, interviews can be prioritized. <a href="http://teambasedconsulting.blogspot.com/2009/08/how-to-deal-with-project-team-that-is.html">See an earlier blog spot for more detail how to deal with this issue</a>.</span></span></span><br />
<br />
<span style="mso-bookmark: OLE_LINK1;"><span style="mso-bookmark: OLE_LINK2;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">In my experience it is impossible to develop strong conclusions and recommendations to a complex issue and convince key stakeholders without carrying out a fairly deep and complex analytical process (otherwise the issue is not really that complex……….). Therefore, if a project team is doing a lot of brain-storming and thinking, and is developing a lot of conceptual slides, but is not doing any analytics to really understand the issues and develop support for their hypothesis it is unlikely that the project will be successful.<span style="mso-spacerun: yes;"> </span>This type of team will need to be forced to do the analytics that are required, and must be given help if they are unable to do so. <a href="http://teambasedconsulting.blogspot.com/2009/08/how-to-help-team-carry-out-meaningful.html">See an earlier blog spot for more detail how to deal with this issue</a>.<o:p></o:p></span></span></span><br />
<br />
<span style="mso-bookmark: OLE_LINK1;"><span style="mso-bookmark: OLE_LINK2;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">If the team has very limited interactions with you and other sponsors this can be a sign that the team is uncomfortable with the progress that they are making. If this is not the case then there is a high risk that they are not getting enough feedback on the direction they are taking and/or the key assumptions that they are making. In my experience, this often leads the team to take off on a tangent that is very different from the expectations of the sponsors. The easiest way of correcting this is to force the team to sit down with you and give an overview of their hypotheses and analytics. <a href="http://teambasedconsulting.blogspot.com/2009/08/how-to-ensure-that-project-team-has.html">See an earlier blog spot for more detail how to deal with this issue.</a></span></span></span><br />
<br />
<span style="mso-bookmark: OLE_LINK1;"><span style="mso-bookmark: OLE_LINK2;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">If key stakeholders are not aware of the project it means that the team is not communicating with them. I have seen very many projects where the internal teams thinks that they only need to present their results at a final presentation without any previous communication with key stakeholders. Usually these projects do not get the agreement and acceptance that is necessary for a good implementation of required activities as expectations have not been managed, ideas have not been tested, understanding of "hot-buttons" not developed, etc. The best way of correcting this is to make communication an integral part of the team's workload, and follow up (and help) in this process. <a href="http://teambasedconsulting.blogspot.com/2009/08/how-to-ensure-that-key-stakeholders-are.html">See an earlier blog spot for more detail how to deal with this issue.<o:p></o:p></a></span></span></span><br />
<br />
<span style="mso-bookmark: OLE_LINK1;"><span style="mso-bookmark: OLE_LINK2;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">The most important signal signifying that a project is not going well is if it is not meeting interim deadlines. Sometimes I have seen internal projects that have not even set internal deadlines. These are extremely likely to fail, as there is not even an opportunity to check if the project is on track. The best way to avoid this danger is a) to set clear intermediate milestones that involve developing and presenting clear results, and b) ruthlessly follow up on the agreed deadlines. <a href="http://teambasedconsulting.blogspot.com/2009/08/how-to-deal-with-project-that-is-not.html">See an earlier blog spot for more detail how to deal with this issue</a>.</span></span></span><br />
<br />
<span style="mso-bookmark: OLE_LINK1;"><span style="mso-bookmark: OLE_LINK2;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">I have often seen teams that are very good at communicating about the process they are going through (we have talked to ten people, we have developed a model, etc, etc) but are unwilling to say anything about the real results (conclusions) coming out of their work. Very often this is a sign that they are not going to present strong conclusions and recommendations at the end of the project. The reasons for this vary. Sometimes it is uncertainty that the leads to believe that they are not "ready" to present conclusions, other times it is mainly driven by the team being uncomfortable with the results and conclusions that are expected of them and/or coming out of the analysis (opportunity to reduce staffing by 20%, etc). The best way to deal with this is to force the team to present conclusions at interim meetings. <a href="http://teambasedconsulting.blogspot.com/2009/09/how-to-help-project-team-develop.html">See an earlier blog spot for more detail how to deal with this issue</a>.</span></span></span><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;"><o:p></o:p></span><br />
<br />
<span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">The more of these symptoms that a team shows, the more likely it is that drastic intervention will be required in order to give the team a chance at achieving its overall goals. The earlier such an intervention takes place, the more likely that it will be successful.<o:p></o:p></span><br />
<br />
<span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">Follow the links if you are interested in more information on </span><a href="http://www.teambasedconsulting.com/index.php/en"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;"><span style="color: blue;">project planning</span></span></a><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;"> or </span><a href="http://www.teambasedconsulting.com/index.php/en"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;"><span style="color: blue;">project management training</span></span></a><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">.<o:p></o:p></span><br />
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt;"><br />
</div>Rune Aresvikhttp://www.blogger.com/profile/10439422800800266511noreply@blogger.com0tag:blogger.com,1999:blog-483658600665838321.post-59975927042334911952011-06-07T16:37:00.001+02:002011-06-07T16:39:25.329+02:00When should you not use consultants?<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh8eOU0flOxAQ7CR0Pi5uU9Rst3zR7yAfNiopNAysboN2wZroSQTaEUcDYxhqB0ZmeRvFslBL9Ae1fw5Q48Q2xal8_ZlRnUPnpmordOd7KU1XR5_o2anOfDJh5qxgYWKHsP_sGF-WL3qzhy/s1600/Wordle-+When+should+you+not+use+consultants.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="231" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh8eOU0flOxAQ7CR0Pi5uU9Rst3zR7yAfNiopNAysboN2wZroSQTaEUcDYxhqB0ZmeRvFslBL9Ae1fw5Q48Q2xal8_ZlRnUPnpmordOd7KU1XR5_o2anOfDJh5qxgYWKHsP_sGF-WL3qzhy/s400/Wordle-+When+should+you+not+use+consultants.jpg" width="400" /></a></div><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">In my previous blog-post I described how you can decide whether a project is complex and therefore either should be outsourced to experts (i.e. external consultants) or be carried out by an internal team, but given special care and attention. Once you have decided that the project you are considering is complex, the next question is therefore how to carry it out.<o:p></o:p></span><br />
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt 2.25pt;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">I have led consulting teams carrying out a broad range of complex projects across Europe for LEK Consulting, PwC, and A.T. Kearney (where I ended up a Partner). The projects I carried out always added value to my clients, but I am convinced that the clients I worked for could have carried out a fair portion of these projects themselves.<o:p></o:p></span></div><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">What did these projects have in common? Essentially, the answer boils down to the companies in question not having a truly good reason for using the external consultant. In my view companies should only use external consultants when they provide something (knowledge, experience, tool/process, etc) which the company does not have itself. At LEK I carried out numerous projects that helped companies identify and value potential acquisition targets in other countries. This was clearly a task which required local knowledge and specific experience which the clients usually did not have. At A.T. Kearney a number of companies hired us to carry out a cost benchmarking using an extensive database that had been developed by A.T. Kearney. This was clearly an activity which a company could not do itself.<o:p></o:p></span><br />
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt 2.25pt;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">Sometimes there are political reasons for using an external consultant. Examples of this are companies that use a report from a well-known consultant to either get a "quality-stamp" on their plans or to have somebody to blame ("according to Consultancy-A we have to reduce staff by 2000 employees"). While "political" has a certain association with something unsavory, <span style="mso-spacerun: yes;"> </span><span style="mso-spacerun: yes;"> </span>I do not see anything intrinsically wrong in this type of use of a consultant if it helps speed up decision making and the implementation of difficult change.<o:p></o:p></span></div><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">The projects I felt that could have been done by the clients themselves where the projects that did not fall in one of the two previous categories. In my opinion, in these cases, the only reasons for bringing in an external consultant (i.e. a team led by me) was doubts about the ability of an internal team to structure the issues, carry out the required analytics, develop conclusions and recommendations, and communicate these in such a way that buy-in and action is created. If this is the case, the focus should then be on understanding why your company does have these abilities and capabilities, and what can be done to improve this situation.<o:p></o:p></span><br />
<br />
<div class="MsoNormal" style="margin: 0cm 0cm 10pt 2.25pt;"><span lang="EN-US" style="font-family: "Arial","sans-serif"; font-size: 12pt; line-height: 115%; mso-ansi-language: EN-US;">If the key issue is basic capabilities, then there are organizations specializing in improving the capabilities of companies to carry out complex projects. An example in Europe is <a href="http://www.internalconsulting.be/index.asp">ICS</a>, based in Belgium but working internationally. If the problem is not so much the available skills and capabilities but rather the ability to define and carry out a successful project then my input is probably better suited. Please go to <a href="http://www.teambasedconsulting.com/"><span style="color: blue;">www.teambasedconsulting.com</span></a> to get a better understanding of why internal projects tend to underperform, and what to do to improve this situation. Another possibility is to take a look around this blog, as I have written about a large number of specific issues and challenges and how these can best be dealt with.<o:p></o:p></span></div>Rune Aresvikhttp://www.blogger.com/profile/10439422800800266511noreply@blogger.com0tag:blogger.com,1999:blog-483658600665838321.post-52267751035642743502011-05-05T16:34:00.003+02:002011-05-05T16:34:00.969+02:00Should you use my services<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgW22wRnJArDPe5lMb_9cSA4C839QnxGKd0R7WccObnAV-V3cLjRoaz8lX_IyZ2rsqdDHkenRwAEmTWJDmjAoIThJ0H4ITBrxzD6nex2huPdJU2NWIsV2XD9CCJ2N1sHSTkXWJyhk3R0B8J/s1600/Wordle-2011-5+Three+Circles.jpg" imageanchor="1" style="clear: left; cssfloat: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="215" r6="true" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgW22wRnJArDPe5lMb_9cSA4C839QnxGKd0R7WccObnAV-V3cLjRoaz8lX_IyZ2rsqdDHkenRwAEmTWJDmjAoIThJ0H4ITBrxzD6nex2huPdJU2NWIsV2XD9CCJ2N1sHSTkXWJyhk3R0B8J/s400/Wordle-2011-5+Three+Circles.jpg" width="400" /></a></div>In recent meetings people have said that they want to introduce me to colleagues but have not been quite sure how to present me. Thinking about this, I realized that I am serving a rather select group, as three conditions have to be fulfilled before you will want to make use of my services. These three conditions are illustrated in the following diagram.<br />
<br />
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYvE5R7C7jRWvvE8dwdz8mHH3pbc_U08zQM4fOJ5VziUC6AV7Q8cqFlVU3lZ2RWumKSiTy2qS265bxhRIabc04fodjp04AIuRKAfgw6nZ0ETaEzlwoYui4XoI5Pw_WtCNqNJNsOyI6W_xP/s1600/Three+circles.jpg" imageanchor="1" style="clear: left; cssfloat: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="300" r6="true" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYvE5R7C7jRWvvE8dwdz8mHH3pbc_U08zQM4fOJ5VziUC6AV7Q8cqFlVU3lZ2RWumKSiTy2qS265bxhRIabc04fodjp04AIuRKAfgw6nZ0ETaEzlwoYui4XoI5Pw_WtCNqNJNsOyI6W_xP/s400/Three+circles.jpg" width="400" /></a><br />
It is clear that if you do not have a complex issue there is no need to think about a project to deal with this issue. And while you have many issues that need to solved, not all of them are very complex. My short-hand description of a "complex project" is often that it is a problem for which you would consider hiring a team of external consultants (pick your favorite brand…………) to deal with. <br />
<br />
If you are happy hiring consultants than this will typically be your first choice. However, there are many reasons for not hiring a team of consultants. Often, price is a consideration (they tend to be expensive) or budget limitations. Sometimes the experience is that using consultants slows down implementation as there are hand-over issues. Other times, companies are just tired of being over-reliant on consultants for dealing with issues they feel that they should be able to handle themselves.<br />
<br />
If you now a) have a complex project, and b) do not want to use external consultants, and c) are convinced that an internal team will deliver "consultancy-grade" results on time, then you are very comfortable and ready to go. However, if your experience with internal project teams dealing with complex issues is that they never deliver on time and never deliver clear and useful conclusions then you have a dilemma. At this moment your choice has traditionally been to either go back and bring in the team of consultants or to accept the weakness of the internal team.<br />
<br />
This is the "sweet spot" in which my experience and methodologies are of value. In my experience an internal team can deliver "consultancy grade" results if the team works in the right way. Results which are provided at a fraction of the expense of using a team of consultants, and results which, by definition, have a high degree of buy-in in the organization, and therefore are quickly implemented.<br />
<br />
Follow the links if you are interested in more information on <a href="http://www.teambasedconsulting.com/index.php/en">project planning</a> or <a href="http://www.teambasedconsulting.com/index.php/en">project management training</a>.Rune Aresvikhttp://www.blogger.com/profile/10439422800800266511noreply@blogger.com0tag:blogger.com,1999:blog-483658600665838321.post-76324629000747185292011-04-28T21:44:00.000+02:002011-04-28T21:44:59.510+02:00How to Identify Dangerous Projects<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj1TORQhlpdqneMxjpdYX_1JjcTC4j5sh6Bctp0RVrD942sJKLWTKWWDlw_MnTlhAWj02Bfn1yJPP5v09Sej7NKhwQQ2RqTD2svcY6zo9GDMKBKIamOwf5Buk-zqQjwjZj-il6IY8MKUoJE/s1600/2011-5+What+are+dangerous+projects.jpg" imageanchor="1" style="clear: left; cssfloat: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="252" j8="true" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj1TORQhlpdqneMxjpdYX_1JjcTC4j5sh6Bctp0RVrD942sJKLWTKWWDlw_MnTlhAWj02Bfn1yJPP5v09Sej7NKhwQQ2RqTD2svcY6zo9GDMKBKIamOwf5Buk-zqQjwjZj-il6IY8MKUoJE/s400/2011-5+What+are+dangerous+projects.jpg" width="400" /></a></div>I often get asked "when do I know which projects require special care or input from external consultants?" My advice is always to analyze and understand the overall complexity of the issue and project. Complex projects are more difficult and fail more often than simple projects, and therefore require more care in setting up and following up (or can better be outsourced to your favorite consultant who is specialized in carrying out complex projects).<br />
<br />
<br />
<div class="separator" style="clear: both; text-align: center;"></div><div class="separator" style="clear: both; text-align: center;"><br />
</div>The follow-on question is invariably "how do I understand which projects are complex, and how can I compare the overall complexity of projects in my portfolio?" his can be done quite easily by understanding the key drivers of project complexity. The overall complexity of any project is driven by a combination of internal and external factors. External complexity consists of factors related to the overall environment in which the project needs to work. Internal complexity is related to the types of activities that the project is required to carry out and the project's internal organization. A project that scores high on both dimensions of complexity (see diagram) should therefore either be given special care, or be outsourced to an external consultant.<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEirPRy0B4azyq_UUwMYWo7OLV2GNtzDxEMNej_zXikHQMz_rWZXXetWkCaAsWbAwUZiLAvfKSlOj_L46VXil0msQI1BcK37PQ9t3yYmwQzJNZYDeccPbfiY3vYpZ4uWo1cMzxT9GAC6cGpP/s1600/Slide1.JPG" imageanchor="1" style="clear: right; cssfloat: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="240" j8="true" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEirPRy0B4azyq_UUwMYWo7OLV2GNtzDxEMNej_zXikHQMz_rWZXXetWkCaAsWbAwUZiLAvfKSlOj_L46VXil0msQI1BcK37PQ9t3yYmwQzJNZYDeccPbfiY3vYpZ4uWo1cMzxT9GAC6cGpP/s320/Slide1.JPG" width="320" /></a></div><br />
External complexity should be analyzed by looking at four specific drivers. Each individual project will have a different combination of external pressure brought on it through the following drivers:<br />
1. Level of pressure from management to achieve concrete and challenging results<br />
2. Openness of goals to interpretation and level of political elements in goal definition<br />
3. Level of expected uncomfortableness to project participants resulting from project results<br />
4. Required level of communication to various stakeholders for getting the necessary buy-in for conclusions<br />
<br />
Each individual project will also vary in its internal complexity. Internal complexity is driven by:<br />
1. Distance of project to day-to-day business<br />
2. Organizational distance of project team members<br />
3. Level of fairly sophicated data collection and analysis required for the project<br />
4. Level of "out of the box" thinking required for developing optimal solutions<br />
<br />
In my interaction with my clients, I typically go through these drivers and factors individually, and score them on a scale of 1-5. In a recent discussion this went approximately as follows:<br />
• The corporate sponsor requires that we deliver a very concrete plan to turn this company around and make it profitable. However, our own management have very different and individual views on how this should happen, their plans are always to the benefit of their own department, and we will need to communicate extensively with them in order to get buy-in for any plans that are developed (high scores of first two and last driver of external complexity)<br />
• Potential team members feel very uncomfortable about carrying out this project, as they worry that it will require them to "fire" colleagues (high score on third driver of external complexity)<br />
• The people earmarked to do the project are excellent mid-level managers, but they have never carried out any strategic analysis or developed cost reduction plans (high score on first driver of internal complexity), but the advantage is that they know each other quite well and have worked together on previous projects (low score on second driver of internal complexity)<br />
• The project will require sophisticated data collected and analytics and the solutions the team delivers will need to be innovative and different from our current "business as usual" approach (high scores on the last two drivers of internal complexity<br />
<br />
Based on this fairly straight-forward discussion and scoring, we were able to agree that the project was very complex and that special care would be required in setting it up and following it on an ongoing basis. Direct actions from my client included ensuring that the project team had a <a href="http://teambasedconsulting.blogspot.com/2010/03/getting-project-team-quickly-up-to.html">structured kick-off meeting</a>, and that the team <a href="http://teambasedconsulting.blogspot.com/2009/08/how-to-ensure-that-key-stakeholders-are.html">planned in ongoing meetings with him</a> to report back on progress, obstacles, and risks. My input included ensuring that the team carried out appropriate analytics, understood the outcomes, <a href="http://teambasedconsulting.blogspot.com/2009/09/how-to-help-project-team-develop.html">developed appropriate conclusions</a>, and <a href="http://teambasedconsulting.blogspot.com/2009/08/how-to-ensure-that-key-stakeholders-are.html">communicated these to all stakeholders</a>. Based on this structured process, the team delivered more than 20 initiatives that will improve profits both in the short and the long term.<br />
<br />
Follow the links if you are interested in more information on <a href="http://www.teambasedconsulting.com/index.php/en">project planning</a> or <a href="http://www.teambasedconsulting.com/index.php/en">project management training</a>.Rune Aresvikhttp://www.blogger.com/profile/10439422800800266511noreply@blogger.com0tag:blogger.com,1999:blog-483658600665838321.post-85624929509974883992011-04-28T16:06:00.001+02:002011-04-28T16:06:00.210+02:00Lessons Learnt<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjHXdrQF5-o0A2D6wN6vEKMsr87i5LlK6Kk2cGYRvb74cOK86pEBaK0Fyhg_gTpQI13I-xaUV3B35n1jKWywvNhfdPaVG4XZQDKTYLTjHy2eoJlOPVo4D-Opru1qfJK9TS09xTcUewlmqAZ/s1600/Wordle+2011-4+Lessons+Learnt.jpg" imageanchor="1" style="clear: left; cssfloat: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="190" r6="true" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjHXdrQF5-o0A2D6wN6vEKMsr87i5LlK6Kk2cGYRvb74cOK86pEBaK0Fyhg_gTpQI13I-xaUV3B35n1jKWywvNhfdPaVG4XZQDKTYLTjHy2eoJlOPVo4D-Opru1qfJK9TS09xTcUewlmqAZ/s400/Wordle+2011-4+Lessons+Learnt.jpg" width="400" /></a></div>In two previous blog entries I have told you about the turn-around project I carried out with an internal project team. Maybe you are getting sick and tired of hearing about it, but I feel that it was a perfect example of how internal teams can carry out projects that most people think will require a large external team of high-powered consultants. I promise that this will the last update dealing with this theme……….<br />
<br />
<br />
The key lessons learnt from this process can be divided into general lessons related to the choice for an internal team, and lessons related to how an internal team dealing with such a complex issue can be helped to become successful.<br />
<br />
The key lesson must be that internal project teams <strong>can </strong>successfully deliver "consultancy-grade" results. Sponsors of this project agree that there are only marginal differences between what this team delivered (including the key fact that it delivered on time) and what their favorite top-level consultant would have delivered. In addition, the work carried out by this team has resulted in automatic buy-in through-out the organization, and a fast and (so far) successful implementation.<br />
<br />
Key lessons from this project related to ensuring that a team will be successful include:<br />
• Ensure that the right people are made available for the project (skills, attitude, network, etc)<br />
• Give the project a flying start by ensuring that that the goals and expected deliverables have been clearly defined<br />
• Give the team a kick-off that enables the team to take ownership of the project (develop hypotheses and approach, etc)<br />
• Follow-up on work done by individual team members to ensure that it follows a logical and focused structure and gives clear conclusions and recommendations that are supported by facts<br />
• Ensure that the team communicates through-out the whole process (internally in the team, to key stake-holders, etc)<br />
<br />
While every situation is specific, I am sure that any project team that follows these fairly generic lessons will be successful. However, the specifics of doing this can be challenging for an organization that is new to this way of working. As evidenced by the <a href="http://www.linkedin.com/profile/view?id=9363483&trk=tab_pro">testimonials</a> given to me at the end of the project I have played a key role in enabling the success of this team.<br />
<br />
Follow the links if you are interested in more information on <a href="http://www.teambasedconsulting.com/index.php/en">project planning</a> or <a href="http://www.teambasedconsulting.com/index.php/en">project management training</a>.Rune Aresvikhttp://www.blogger.com/profile/10439422800800266511noreply@blogger.com0tag:blogger.com,1999:blog-483658600665838321.post-65330338293710075472011-04-21T15:46:00.001+02:002011-04-21T15:46:00.191+02:00Use a project team to plan a turn-around (2/2)<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhrkozJw_Lv8-_bZDpLtA7wd6xusyg3gHJKcLVmJ67GaijMdHVWTwvivU_k5AE6sah_TXQchyphenhyphenZXTbvtZghKkCM9HmBkA_SED9wHfjs6MknMmTBkQkeF2hJkynh8lHDOJXA2BnybR5aM-0BN/s1600/Wordle+-Use+a+project+team+to+plan+a+turn-around-2.jpg" imageanchor="1" style="clear: left; cssfloat: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="210" r6="true" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhrkozJw_Lv8-_bZDpLtA7wd6xusyg3gHJKcLVmJ67GaijMdHVWTwvivU_k5AE6sah_TXQchyphenhyphenZXTbvtZghKkCM9HmBkA_SED9wHfjs6MknMmTBkQkeF2hJkynh8lHDOJXA2BnybR5aM-0BN/s400/Wordle+-Use+a+project+team+to+plan+a+turn-around-2.jpg" width="400" /></a></div>In my previous blog-post I described how a project team developed a structured overview of the reasons for an engineering company being structurally loss-making. In this post I will give a short overview of the initiatives that were developed to turn the company around and the implementation plan used to ensure that the initiatives will be carried out.<br />
<br />
<br />
<br />
A total of 20 initiatives were developed by the team in four main areas:<br />
•Improved marketing through more focused use of distribution channels, focus on certain segments, and a move away from selling small (loss-making) projects<br />
• Professionalizing the end-to-end process for selling and carrying out projects (clearer scope definition, value- instead of cost-based pricing, improved hand-overs to the engineering teams, more intense follow-up of budgets, etc)<br />
• Large reduction of supporting costs through a detailed added-value analysis of existing activities<br />
• Structural reorganization of the company, leading to less management layers, clearer and more focused responsibilities, etc<br />
<br />
Implementation of the 20 initiatives has been closely linked to the new organization structure, with relevant managers having clear responsibility for specific initiatives. Each initiative has been described in detail and including a high-level implementation plan. The first responsibility for the relevant managers is to develop a more detailed plan (in order to develop ownership) for the individual initiatives under his/her responsibility. Progress on the initiatives will be a key element of the weekly management team meetings and will also be including in the monthly meeting with the corporate sponsor. <br />
<br />
My latest update from management and corporate sponsors is that implementation is going well, and that they are optimistic that the company will finally become profitable and better positioned in the market.<br />
<br />
Follow the links if you are interested in more information on <a href="http://www.teambasedconsulting.com/index.php/en">project planning</a> or <a href="http://www.teambasedconsulting.com/index.php/en">project management training</a>.Rune Aresvikhttp://www.blogger.com/profile/10439422800800266511noreply@blogger.com0tag:blogger.com,1999:blog-483658600665838321.post-58740058806113860942011-04-14T15:39:00.000+02:002011-04-14T15:39:54.601+02:00Use a project team to plan a turn-around<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhZWhbbfXNVMsek2SGC-KAPAMrj11M9prM6i58dJJkuGW-5E0Av4aYxiIwq2l2lj-tdPIpX5AlgK5MqqzvjVFjb7So3-ViTW-xY33tBr4ZPMfvxWMJ6hP_zC6sTBJLAGD6evKK-W9a-nMWz/s1600/Plan+a+turnaround+with+internal+team.jpg" imageanchor="1" style="clear: left; cssfloat: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="223" r6="true" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhZWhbbfXNVMsek2SGC-KAPAMrj11M9prM6i58dJJkuGW-5E0Av4aYxiIwq2l2lj-tdPIpX5AlgK5MqqzvjVFjb7So3-ViTW-xY33tBr4ZPMfvxWMJ6hP_zC6sTBJLAGD6evKK-W9a-nMWz/s400/Plan+a+turnaround+with+internal+team.jpg" width="400" /></a></div>Some months ago I helped an engineering company plan a turn-around. The engineering company is part of a larger company, and has been consistently loss-making for the last five years. New owners decided that "enough is enough" and asked the management to come up with a restructuring plan. The results of this process were an unchanged strategy, minor changes to the organization, and some ad-hoc cost-saving initiatives.<br />
<br />
<br />
This resulted in a high level of frustration at the corporate level, and the general opinion was that external consultants would need to be called in. Fortunately, wiser minds prevailed and it was suggested to use my proven approach for enabling internal teams to carry out complex projects successfully.<br />
<br />
My first suggestion was to move the responsibility for developing the turnaround plan away from the management team to a separate project team. A team was selected consisting of a fairly young group of female middle-managers who had critical minds, good analytical skills, and the ability to think "outside of the box", and were respected within the organization.<br />
<br />
A kick-off meeting was spent agreeing the overall approach to the project. Key outcomes was an agreement on a phased approach (with a clear separation between a first phase focusing on fact-finding and understanding the key issues, and a second phase to develop new initiatives) and use of a hypotheses-driven approach (as used by all major consultants). <br />
<br />
In the first step we developed a hypothesis that the engineering company needed to leave behind its current approach to its business (offering a coordinated suite of engineering related services to the same customers) and focus on understanding the intrinsic attractiveness of what should be seen as separate business-areas. The CEO attended this meeting, and defended the existing strategy, but accepted the overall logic suggested by the team.<br />
<br />
During the next few weeks the team focused on developing proof for the hypotheses developed in the first meeting. This involved understanding the markets in which the company operated, analyzing the operating processes, and developing a financial overview of the individual business areas and projects. The team agreed that the hypotheses-driven manner of working was helpful as it gave the team clear objectives to work toward and enabled a very focused and effective way of working.<br />
<br />
The results of the diagnostic phase supported most (but not all) of the original hypotheses developed by the team. A key finding supported the decision to look at the business areas independently. Different from what we originally believed, it turned out that all the business areas provided a positive contribution to the overall profitability of the business. However, the contribution from each business was small. This was caused by a wide range of marketing and operational issues. Marketing issues included too many small loss-making projects, incorrect pricing methods, and insufficient focus on existing, profitable customers. Operational issues included insufficient planning of projects, low follow-up of budgets, and a lax attitude towards scope creep and up/cross-sell. <br />
<br />
The final step in the diagnostic phase was to communicate the findings to the management team and the corporate sponsor of the project. The key challenge with the management team was getting buy-in to the radically different picture of the company that the team presented. Based on the thoroughness of the analysis and the pyramid based presentation this went well. The corporate sponsor was very happy with finally receiving a structured analysis of why the company was loss-making and asked the team to continue with the developed of initiatives and an implementation plan.<br />
<br />
Follow the links if you are interested in more information on <a href="http://www.teambasedconsulting.com/index.php/en">project planning</a> or <a href="http://www.teambasedconsulting.com/index.php/en">project management training</a>.Rune Aresvikhttp://www.blogger.com/profile/10439422800800266511noreply@blogger.com0tag:blogger.com,1999:blog-483658600665838321.post-43571234114926166002010-11-16T10:51:00.000+01:002010-11-16T10:51:23.382+01:00Ensure Project Success by Demanding Proposal<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgfCKVAeJV8c_6AEjLT2JU7UU5s79hDNC-4nljsOtWRLfqZJGE_ZNx8jVqzdyRqZek9VzhY5ttneG1GCX_A4nKGZBaoLGOo4gTBSPr0SHUGVrMrObpKN4iRYe6PEsylHXpM906-tFBgMp0S/s1600/Wordle+-+Ensure+Project+Success+by+demanding+Proposal.jpg" imageanchor="1" style="clear: left; cssfloat: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="195" px="true" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgfCKVAeJV8c_6AEjLT2JU7UU5s79hDNC-4nljsOtWRLfqZJGE_ZNx8jVqzdyRqZek9VzhY5ttneG1GCX_A4nKGZBaoLGOo4gTBSPr0SHUGVrMrObpKN4iRYe6PEsylHXpM906-tFBgMp0S/s400/Wordle+-+Ensure+Project+Success+by+demanding+Proposal.jpg" width="400" /></a></div>I am sure that most of you have been the sponsor of projects that have not reached their objectives in a satisfactory manner. In these situations, you have probably wondered if you as the sponsor could have done something to make the project a success.<br />
<br />
<br />
In my experience, there is one action that you as a sponsor can take that will greatly increase the success rate of internal projects. This is to demand that the project manager (and team) develop a proposal similar to what you would expect from an external consultant. You will the need to evaluate the proposal in the same way that you would evaluate a proposal from your consultant. This includes concluding whether the proposal from the internal team:<br />
<br />
• Shows that the team truly understands the core issues that you need to have dealt with<br />
• Suggests goals and deliverables that will actually help you deal with your core issues<br />
• Presents an approach that makes sense by suggesting a reasonable set of activities, use of time and resources that both meet your deadlines and are reasonable, and presents a set of milestones that show how the project will move forward and gives you the opportunity to easily understand whether the project is on-track<br />
<br />
If you are not satisfied with the proposal you then have the option of sending the project team back to the drawing board or to consider other options (including external consultants). <br />
<br />
While a well-structured and agreed proposal is a key success factor, it really shows its value when it is used as part of your top-level management of the project. A key component of this process is to insist that the project team sticks to the agreed deadlines and milestones (as is second nature to external consultants). <br />
<br />
Follow the links if you are interested in more information on <a href="http://www.teambasedconsulting.com/index.php/en">project planning</a> or <a href="http://www.teambasedconsulting.com/index.php/en">project management training</a>.Rune Aresvikhttp://www.blogger.com/profile/10439422800800266511noreply@blogger.com0tag:blogger.com,1999:blog-483658600665838321.post-49660998951695140762010-10-07T15:58:00.001+02:002010-10-07T15:59:30.813+02:00Interesting article in Harvard Business Review<div class="separator" style="clear: left; cssfloat: left; float: left; margin-bottom: 1em; margin-right: 1em; text-align: center;"><img border="0" ex="true" height="181" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgOwCakfXno4AMXfE3FU7llC7m8qhMSYQdTA6jOWXhHb_FH_lTpYFSp6Pu-nPnRBHmcQODZqnqEZus4LkFjgLjKze5ZANIEzQyJKAjts9hZhd1lJZQfczHk_S4g2Z2BC3HiwOmJXnonSun3/s320/26-+Blogspot+on+Harvard+Article.jpg" width="320" /></div><br />
<br />
<span style="font-family: Arial, Helvetica, sans-serif;"></span><br />
<span style="font-family: Arial, Helvetica, sans-serif;">In the September number of Harvard Business Review there is a very interesting article, <a href="http://hbr.org/2010/09/four-mistakes-leaders-keep-making/ar/1">"Mistakes Leaders Keep Making", by Robert H. Schaffer</a>. This article highlights four behavioral traps that thwart organizational change. It is an excellent article, and while the focus is on organizational change and the relationship between executives and subordinates, the issues highlighted and the suggested solutions are directly transferable to teams carrying out complex projects. My translation of his behavioral traps to a team setting is: <br />
<br />
<br />
• Behavioral trap 1 : Executives and sponsors typically fail to set proper expectations for the teams carrying out critical but complex projects<br />
<br />
• Behavioral trap 2: Teams carrying out complex projects are not staffed with the appropriate people because they are "too busy" and/or are protected by their line managers<br />
<br />
• Behavioral trap 3: It is safer psychologically to "sign a fat check to a consultant and hope for the best"<br />
<br />
• Behavioral trap 4: Delays in reaching key milestones are tolerated if the project team is able to point to dependencies to other company activities (we need a new computer system before we can………………..)<br />
<br />
<br />
<br />
I believe that these behavioral traps are very similar to the "seven deadly sins" I have written about in previous blog-entries. This means that these issues can be addressed by going through a step-by-step process to ensure that the internal project is set up correctly, and by carefully carrying out an ongoing quality and timeliness controls. Follow the links if you are interested in more information on <a href="http://www.teambasedconsulting.com/index.php/en">project planning</a> or <a href="http://www.teambasedconsulting.com/index.php/en">project management training</a>.<br />
<br />
</span>Rune Aresvikhttp://www.blogger.com/profile/10439422800800266511noreply@blogger.com0tag:blogger.com,1999:blog-483658600665838321.post-53033890555976653972010-03-22T14:24:00.001+01:002010-03-22T14:24:00.777+01:00Getting a Project Team Quickly Up To Speed<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh1jGbX4L_0i5lJL8GU2IcBVSOjLE71HVmQTepj5FhLj8FszI1mr-3efdCsELClhSs_5SpFvq2-LfrVrUvcJ8EmirlARUlw9sl8DeKQdW0vjJWItYEWynbuC6YsdknfisMa-IxbujQVL57X/s1600-h/Wordle+-+getting+a+project+Team+Quickly+Up+To+Speed.jpg" imageanchor="1" style="clear: left; cssfloat: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="203" kt="true" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh1jGbX4L_0i5lJL8GU2IcBVSOjLE71HVmQTepj5FhLj8FszI1mr-3efdCsELClhSs_5SpFvq2-LfrVrUvcJ8EmirlARUlw9sl8DeKQdW0vjJWItYEWynbuC6YsdknfisMa-IxbujQVL57X/s400/Wordle+-+getting+a+project+Team+Quickly+Up+To+Speed.jpg" width="400" /></a></div>I am currently in the process of carrying out a project at a European energy company. In this project I have helped the project team recover from a disastrous first phase by helping set up a structured and fast start to the second phase of the project. <br />
<br />
<br />
The project was originally staffed with a team of eleven technical people from across the company. The people chosen for this team represented a wide range of departments that dealt with the technology. The team worked for four weeks, and presented its results. The Steering Committee was disappointed with these results, as it felt that a) the team had not addressed the key issues, and b) had not developed a sufficiently detailed analysis of the "facts and figures" related to the technical elements being analyzed. A number of things went wrong in the first phase, and my key role has been to correct these issues in the second phase of the project.<br />
<br />
The main problem the project team faced was that it had too little time to carry out any actual analytics. This was caused by an unrealistic deadline imposed by the steering committee, but also by the project using almost two weeks of the available four weeks in starting up the project and carrying out "team building" activities related to agreeing the goals and deliverables of the project. The excessive time spent on starting up the project was due to a number of inter-linked reasons. The key reasons are cultural, habit, politics, and insecurity in project leadership:<br />
• The company in question is from Northern Europe, where egalitarianism is important. This general cultural trait is strengthened by the culture of the company itself which is also fairly flat in its structure, and believes in everybody having the right to state their opinions. This results in "open debate" being the default solution for setting up this type of projects.<br />
• Habit was in this case mainly driven by the use of an internal process manager, who (rightly or wrongly) believed that this was the way that projects should be run. In this company, the type of team building through the bottom-up development of goals, deliverables, approach, etc is "the thing" that project managers do, and which probably work fairly well in this culture if the project has sufficient time.<br />
• Politics played a key role in this project, as the best way forward for the technological asset being discussed was a highly political issue with extreme differences in opinions across the various departments of the company. This meant that all the team participants felt that they had to "push" their preferred solutions rather than focusing on the work to be done.<br />
• The project leadership (both the formal project manager and the internal process manager) were open about not being used to running this type of complex project. This meant that they were not sure about how best to structure such a project, and were uncomfortable with "pushing" their views in a group of experts.<br />
<br />
The second phase of the project was set up to minimize the problems encountered in the first phase and to maximize the probability of the project team being successful. The project <a href="http://teambasedconsulting.blogspot.com/2009/11/choosing-project-leader.html">started with the project leader</a>. The project leader developed a very clear and structured overview of what the Steering Committee / key sponsors were looking for (goals and deliverables). This was put on paper, and tested with the sponsor / steering committee, and adjusted as required to ensure that the expectations on what will be delivered were 100% clear. Based on this, the project leader developed an overall approach for reaching the goals and deliverables. This plan included a small core team and a realistic estimate of the time required for reaching the agreed deliverables.<br />
<br />
When agreement was reached with the steering committee and sponsor the project leader brought together the chosen team, and communicated the results of the first step. He asked the team for comments and feed-back, and adjusted the details of the plan for the good ideas and comments that were given. The structured and hierarchical start of the project meant that this process took less than one week instead of the two weeks in the first iteration of the project, and was also much more efficient as the total man-hours used were 25% of that used the first time around.<br />
<br />
The structured and hierarchical start has also meant that politics have been minimized and effective use of the available resources maximized. The core project-related activities have been carried out through a mixture of sub-teams doing specific analytical tasks (within agreed milestones) and presenting and discussing the results with the rest of the project team. The role of the project manager in this phase has been to strictly follow-up on scope (is the team focusing on what they should be doing?), analytics (is the work being carried out correct?), quality of results (are the outputs from the team's work what it needs to be), and coordinating the work of the different work-streams.<br />
<br />
At agreed moments the project manger and the core team have brought together the work of the individual teams and developed the overall conclusions and story-line. This has been presented to the whole project team and discussed (and revised) until the team agreed to the overall conclusions. The results were then presented to the steering committee in the form of interactive workshops.<br />
<br />
The project is now in the final phase and the results are being <a href="http://teambasedconsulting.blogspot.com/2009/08/how-to-ensure-that-key-stakeholders-are.html">discussed with the individual steering committee members</a> before the final presentation. This will ensure a broad agreement to the conclusions that the project has developed and commitment to the follow-up actions suggested by the team. <br />
<br />
Follow the links if you are interested in more information on <a href="http://www.teambasedconsulting.com/index.php/en">project planning</a> or <a href="http://www.teambasedconsulting.com/index.php/en">project management training</a>.Rune Aresvikhttp://www.blogger.com/profile/10439422800800266511noreply@blogger.com0tag:blogger.com,1999:blog-483658600665838321.post-86312317720196044902010-02-28T11:26:00.001+01:002010-02-28T11:26:00.269+01:00The Business case For Improving Complex Projects<div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjp4IHQ2FPb-yOjdI8LZjyOK42b1DFRQJNAzM_JfTz2b5MRvWBRmc-blcfoyHUUv88pU1OlFE1rV3ti1oW7deHckQ3XnC3ikUJ0JrlGptDMbal-j9Tj1aRnwOqxB7mbJh6gvHlqDfCdn-8T/s1600-h/Wordle+-+The+Business+case+For+Improving+Complex+projects.jpg" imageanchor="1" style="clear: left; cssfloat: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="187" kt="true" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjp4IHQ2FPb-yOjdI8LZjyOK42b1DFRQJNAzM_JfTz2b5MRvWBRmc-blcfoyHUUv88pU1OlFE1rV3ti1oW7deHckQ3XnC3ikUJ0JrlGptDMbal-j9Tj1aRnwOqxB7mbJh6gvHlqDfCdn-8T/s400/Wordle+-+The+Business+case+For+Improving+Complex+projects.jpg" width="400" /></a>As you probably know, my core business is to help improve the performance of internal teams carrying out complex projects. In discussions with executives concerning input from my side I am often asked to define the business case for using my services. This question has become steadily more usual in the last year, as it has become progressively more difficult for companies to hire in external help.</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"></div><br />
<div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">The direct value of my input is difficult to quantify as my service is secondary. Therefore, my initial reply focuses on helping the executive understand the business case for the project he thinks is in trouble.. If this is non-existent, or very difficult to quantify, my advice is that the project should be stopped. For some projects, such quantification is fairly easy. If the project in question is a cost reduction project, the value of the project is driven by the size and timing of the savings to be implemented. If the project focuses on product development, the value of the project is driven by the revenues and profits expected to result from the new product. </div><br />
<div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">For other types of projects, such quantification is more difficult, but can usually be carried out. For a strategy project, the value can be very high, but the quantification needs to take into account follow-up projects required for implementation, etc. For a reorganization project, the value should come from improved decisions, better use of resources, etc. This is all fairly indirect, but clearly has value.</div><br />
<div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">If the overall project has value, it is then critical to understand that this value can be radically reduced by a number of issues related to how the project is carried out. Any of the "<a href="http://teambasedconsulting.blogspot.com/2009/07/eight-signs-that-your-project-is-in.html">8 deadly sins of complex projects</a>" will lead to such a loss of value, but I will focus on a few concrete examples.</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">If a project is <a href="http://teambasedconsulting.blogspot.com/2009/08/how-to-deal-with-project-that-is-not.html">delayed because it is not meeting its deadlines</a>, then this has a direct effect on the value of the project. Let us assume that the project will increase annual profits by €1 million. This can be the result of a cost reduction program with a €1 million bottom line effect, or a new product launch with annual sales of €4 million, 25% margins, and negligible "fixed" costs. In this case, a one-month delay in the project means that your company will have a one-off (but permanent) loss of €0.1 million in profits.</div><br />
<div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><a href="http://teambasedconsulting.blogspot.com/2009/08/how-to-help-team-carry-out-meaningful.html">Lower quality results from the projects</a> will also have direct consequences on the value. Let us assume that the cost reduction project mentioned earlier does not identify all the cost saving opportunities that were available and/or expected. If the project only identifies €0.9 million bottom-line effects instead of the €1 million that is believed to be available, then the annual loss is €0.1 million. In the product development example used earlier, then a fairly minor mistake in the product definition and/or pricing that leads to 3% less revenues will lead the same ongoing annual loss of €0.1 million.</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">A project team that <a href="http://teambasedconsulting.blogspot.com/2009/08/how-to-ensure-that-key-stakeholders-are.html">does not communicate optimally</a> can lead to the same type of value-loss. If the work carried out is good, but the results are not accepted and therefore not implemented, then the loss of value is 100%. If the unsuccessful communication leads to lower buy-in resulting in either delays or only partial implementation then the consequences will be the same as in the previous example (i.e. ongoing annual losses). </div><br />
<div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">My experience is that using the Team Based Consulting methodology to provide structured help to project teams (including the executive sponsor) in a) defining and setting up the project, b) carrying out the project, and c) developing and carrying out a communication process can easily help avoid the type of value-loss given in these examples. Given the fairly focused and limited input that is required from my side to help the internal teams, the business case for such an intervention can almost always be made.</div><br />
Follow the links if you are interested in more information on <a href="http://www.teambasedconsulting.com/index.php/en">project planning</a> or <a href="http://www.teambasedconsulting.com/index.php/en">project management training</a>.<br />
<div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><br />
</div>Rune Aresvikhttp://www.blogger.com/profile/10439422800800266511noreply@blogger.com0tag:blogger.com,1999:blog-483658600665838321.post-62503597177774268232009-12-04T10:33:00.005+01:002009-12-04T10:33:00.511+01:00Using Internal Consultants in Complex Projects<div class="separator" style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none; clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgh3G1tY_jWd2SSFYTunMTz0BsuktRJSAzJx-uagQJWjj5po-AUdBNjPGMLMlCcpwPcX8mk-nEx6iC1jSdCC-mx5GAwijJyG2OHmZra6guv8Kk7qfKoxFwULymvzL_tJ9YuXKe2IZmy7UNF/s1600-h/Using+Intrnal+Consultants+in+Complex+Projects.jpg" imageanchor="1" style="clear: left; cssfloat: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgh3G1tY_jWd2SSFYTunMTz0BsuktRJSAzJx-uagQJWjj5po-AUdBNjPGMLMlCcpwPcX8mk-nEx6iC1jSdCC-mx5GAwijJyG2OHmZra6guv8Kk7qfKoxFwULymvzL_tJ9YuXKe2IZmy7UNF/s320/Using+Intrnal+Consultants+in+Complex+Projects.jpg" vr="true" /></a><br />
</div><br />
It was recently pointed out to me that a new advisor has started up that assists companies in setting up internal consulting groups. This started me thinking about the possible role that internal consultants can play in improving the way that complex projects are carried out in most companies.<br />
<br />
<br />
The new advisor is clearing playing in on the trend for large, international companies to set up their own internal consulting groups. These internal organizations are usually staffed with alumni of well-regarded, blue-chip consulting companies, and are then used (sometimes, but not always) instead of external consultants. The paradox that I see from my discussions with executives is that opinions are evenly divided among those having a positive view and those having a negative view on the success of projects carried out by the internal consulting groups. <br />
<br />
Some of the executives I speak to tell me that they do not have the typical issues that I usually see with internal teams carrying out complex projects due to the input of the internal consultants. Other executives tell me that even with the presence of internal consultants, their complex projects tend to have many of the issues that I raise and that their projects are therefore often not successful. Based on this, there seems to me to be an issue related to how these internal consultants are being used. <br />
<br />
The typical way that they are used by most companies is that the complex projects are outsourced to the internal consultants instead of to external consultants. In other words, a team from the internal consultants group is a replacement for the usual teams of external consultants. This certainly has a number of positive aspects. It will certainly save the company the typically high costs of engaging an external consultant. In addition, the internal consultants have a number of advantages compared to the company's average employees. The internal consultants usually have strong analytical skills, are used to carrying out projects, have fairly high interpersonal skills, and typically know the consulting "tricks of the trade".<br />
<br />
While the internal consultants have many of the positive aspects of external consultants, they, unfortunately, also have many of the negative aspects as well. Often, a team coming from the internal consulting group will be viewed as outsiders by the organizational units they are providing assistance to. The team from the internal consultants will typically not have in-depth knowledge of the specific area that the project is dealing with. In addition, it is my experience that internal; consultants often have their own political agenda. The reason many people have switched from a consulting company to an internal consulting organization is that they view this as a stepping stone to a corporate job. These people are therefore often viewed as being on the look-out for situations where they can prove that the current management is doing a bad job so that they can position themselves to take over. <br />
<br />
In addition, internal consultants are often viewed as working for top-management, and not having the best interests of the local organization in mind. Finally, using the internal consulting group often brings with it many of the same issues as outsourcing a project to external consultants. A project carried out by internal consultants will typically meet resistance based on the "not invented here" syndrome, and will therefore have low buy-in, typically resulting in a delayed and/or less successful implementation.<br />
<br />
My overall conclusion is that there is a role for internal consultants in complex projects. However, they should be given total control of projects only in a limited number of situations. Giving complex projects to an internal consultants group can be a good solution if a) the project is for top management, b) there are specific issues related to speed or secrecy (acquisitions, etc), c) there is a very high need for complex analytics. <br />
<br />
In other situations, the internal consultants group should be used as part of the overall resource pool for staffing complex projects across the organization. The staff from this group will typically be extremely well suited for providing the required analytical and communicative skills to the team. However, as shown by the earlier comments made by executives in organizations using internal consultants, even projects staffed by internal consultants should not be left alone, as there is still a good probability that one or more of the eight deadly sins will be committed by the team.<br />
<br />
Follow the links if you are interested in more information on <a href="http://www.teambasedconsulting.com/index.php/en">project planning</a> or <a href="http://www.teambasedconsulting.com/index.php/en">project management training</a>.Rune Aresvikhttp://www.blogger.com/profile/10439422800800266511noreply@blogger.com0tag:blogger.com,1999:blog-483658600665838321.post-44835120161325416552009-11-27T15:44:00.001+01:002009-11-27T15:44:00.163+01:00Choosing a Project Leader<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiKeyPtIycx_g28qV_Z3isl4pG7z-mUHRPAecr9APcAjZ9mXdgHS7pBro6lwfU9M1fjusKSfhHpY4lpMNLB4poVcQtgMHHROnkfNMAJyfLfKztxMZZssh4PXMjMSr3NNMd05w0CJVLqKcEj/s1600-h/Choosing+a+project+leader.jpg"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5393940000266301650" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiKeyPtIycx_g28qV_Z3isl4pG7z-mUHRPAecr9APcAjZ9mXdgHS7pBro6lwfU9M1fjusKSfhHpY4lpMNLB4poVcQtgMHHROnkfNMAJyfLfKztxMZZssh4PXMjMSr3NNMd05w0CJVLqKcEj/s320/Choosing+a+project+leader.jpg" style="cursor: hand; float: left; height: 152px; margin: 0px 10px 10px 0px; width: 320px;" /></a><br />
In a recent discussion with a potential client, he told me that he was in the process of setting up a team to lead a cost-reduction project in his 1000 employees company. He explained that this project was crucial to the company's short-term survival, but that he did not want to compromise the company's longer-term competitiveness due to short-term cost reduction initiatives. His question to me was how he could decide which person to ask to lead this crucial project.<br />
<br />
I explained that I agreed that putting together the right team would be crucial for enabling the success of this very complex project, and that choosing the project leader was the first, and maybe most crucial, step in this process. However, I also told him that the choice of the project leader could not be looked at independently of the choices required for the rest of the team. We discussed how the key goal of putting together a project team is to have the right mix of skills and experience. We agreed that this boiled down to the members of the team having the right mix of problem solving / analytical skills, interpersonal skills, and technical/functional skills. In addition, the team should span the parts of the organization covered by the project in order to ensure that nobody feels "left out".<br />
<br />
The team required for a project depends on the phase of the project being carried out. In this case, the cost reduction project was just starting up (see <a href="http://teambasedconsulting.blogspot.com/2009/10/how-to-get-buy-in-for-project.html">Determining the Appropriate Deliverables for the First Phase of a Project</a>) and the focus was on developing a detailed understanding of the situation and key issues faced by the company, to make an overview of key changes required (by how much do costs need to be reduced in order to be competitive and profitable?), and to suggest the overall direction of possible improvements. In this case, I explained that the overall team needed to be fairly small, and consist of people that:<br />
·Know the company well enough to understand where the issues and fat lie<br />
·Are not too constrained by "we already tried that…………:"<br />
·Are analytically strong and able to dig up data to support their conclusions and recommendations<br />
·Are able to think "out of the box" and develop strong ideas on how the main processes of the company could be changed (with reduced costs and (often) improved results)<br />
·Are good communicators able to get input from across the company<br />
·Are sufficiently respected within the company that people will listen to them<br />
<br />
The potential client told me that he had some people in mind for the project-team, but was worried about their age and knowledge of the company. I told him that in my experience, a team to carry out this type of activities can be quite young, as it often will be easier for them to carry out the analytical tasks and do the "out of the box" thinking. However, this entails that the key role of the project leader will include managing and quality controlling the work of the rest of the team, and being the main interface between the team and the rest of the organizations. Based on this, I explained that the project leader would need to be somebody who has a fair bit of working experience in the company (ideally in different roles), is fairly strong analytically, but not necessarily an Excel-whizz, is able to mentor and manage a team of younger staff, and is able to communicate well with people across the company and at all levels of the organization (see <a href="http://teambasedconsulting.blogspot.com/2009/08/how-to-ensure-that-project-team-has.html">How to Ensure That The Project Team Has Sufficient Interaction with Sponsors</a> and <a href="http://teambasedconsulting.blogspot.com/2009/10/how-to-get-buy-in-for-project.html">How to Get Buy-In for Project Conclusions and Recommendations</a>) .<br />
<br />
In going through the potential candidates for the project leader role, I quickly focused on a candidate with an MBA, and who had gotten to the mid--management level of the company fairly quickly after having worked in two or three jobs across the company and gained experience in different functions related to marketing and production. My potential client explained that it would be extremely difficult to free this person from his current tasks for the duration of the cost reduction project. After a discussion where we talked about how crucial this project <strong>REALLY</strong> was, he finally agreed that he would need to use the best person for the project.<br />
<br />
While this blog is based on a specific example, following the general rules and ideas suggested here will help anybody who is in the process of setting up a complex project.Rune Aresvikhttp://www.blogger.com/profile/10439422800800266511noreply@blogger.com0tag:blogger.com,1999:blog-483658600665838321.post-53001838381482853022009-11-20T12:18:00.002+01:002009-11-20T12:18:00.199+01:00Ensure that Projects Finish on Time by Avoiding Scope Creep<div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjyzSOpq2-Tw8gzghe2jZm1O5yxMwMNBTW58XJpxQ-0T8gz6Z-bwtrejykW6WCLTeLaLwY6ElFjT4XsiXeflUgtYV8fnEQHzBCSXhyaSIIZYS5b-oiZlvWQqyRgv7kGfIe_hIsKBrHkTdvV/s1600-h/24-+Avoiding+scope+creep.jpg" imageanchor="1" style="clear: left; cssfloat: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" sr="true" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjyzSOpq2-Tw8gzghe2jZm1O5yxMwMNBTW58XJpxQ-0T8gz6Z-bwtrejykW6WCLTeLaLwY6ElFjT4XsiXeflUgtYV8fnEQHzBCSXhyaSIIZYS5b-oiZlvWQqyRgv7kGfIe_hIsKBrHkTdvV/s400/24-+Avoiding+scope+creep.jpg" /></a>In my discussions with executives, the most common complaint they have about internal project teams is that they hardly ever deliver the agreed end-results on time. While there are a<a href="http://teambasedconsulting.blogspot.com/2009/07/eight-signs-that-your-project-is-in.html"> number of reasons why this typically happen</a>s, one of the most common reasons is scope creep. Scope creep can be defined as the tendency for project team to carry out more work than originally agreed and/or is required for making the project a success. There are two different types of scope creep (external and internal). The reasons for the two types are different, as are the steps required to ensure that it does not happen, or that the consequences are limited. These two types will therefore be described separately.<br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><br />
</div><br />
<div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">External scope creep is caused by <a href="http://teambasedconsulting.blogspot.com/2009/08/how-to-ensure-that-project-team-has.html">sponsors</a> or other <a href="http://teambasedconsulting.blogspot.com/2009/08/how-to-ensure-that-key-stakeholders-are.html">stakeholders</a> asking the project team to carry out more work than was originally agreed. The natural tendency of most project managers and project teams is to blindly say "yes" without thinking about the consequences. In fact, sometimes extra work is welcomed by the team, as it gives the team an excuse for not finishing on time. The primary responsibility for guarding against external scope creep lies with the project manager. <br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">The project manager needs to guard against scope creep by ensuring that all requests for additional work are known to him. When he is made aware of a request for additional work he should carefully assess whether the requested work fits within the scope of the project and whether it can be done within the agreed resource and time limitations. If this is not the case, then he and the team should discuss the issue with the sponsor and agree the solution. The solution can be a) not performing the extra activities, b) performing the extra activities but dropping another activity, or c) performing the extra activity and extending the available time or increasing available resources. The project manager should use the project charter as the basis for discussions on this topic. While this will not “magically” ensure that the project is completed on time, it will, at the very least, enable a structured discussion on priorities.<br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">Internal scope creep is when the project team decides to do more work than agreed and/or is required for meeting the project goals. A clear example of such a situation is a project I am currently helping. In this project the team consists of people from different technical departments within a large network company. The team has been given the responsibility for developing a telecoms vision for the next ten years. The team has been given considerable freedom in defining its specific deliverables and project approach, but has also been given a very tight deadline. The naturally tendency of such a team is for everybody to raise the issues that are critical for their department, and make suggestions for activities that they personally find interesting. Because the team is democratic in its approach, it is very difficult to prioritize or censor, resulting in a very broad list of activities to be carried out.<br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">My help so far to this team has focused on helping them to understand the exact need driving the request from their management team. Using this, we have been able to <a href="http://teambasedconsulting.blogspot.com/2009/09/determining-appropriate-deliverables.html">focus the goals of the project</a> on helping to resolve the core issues that the management is facing. Using this as a starting point, we have then carefully developed a work plan focusing only on understanding the key drivers for the requirements to be placed on the company's telecom services in the next ten years. In parallel, we are defining a work stream that will help us understand how the telecom service provider environment will evolve. Combining these two activities will enable the team to give the management team the vision it required for making key asset-related decisions. <br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">This step has only given a starting point for controlling scope creep, as the real danger will lie in the day-to-day activities being carried out by the team. We have therefore agreed that in the ongoing review of the activities being carried out by the team members and sub-teams we will use a "scope test". Essentially, this "scope test" consists of a diagram showing the inner-most circle of telecoms related assets, services, requirements, etc, and an outer ring which includes all the direct influencers of the internal ring. If there is doubt about an activity being carried out, it will be placed in the diagram. If it is not located in the two inner-most circles, it will be seen as being out-of-scope and discontinued.<br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">In addition to this "yes/no" decision regarding activities, we have also agreed to have an ongoing dialog on the depth of the analysis being carried out. The team mainly consists of engineers, whose normal work requires 100% accuracy. Given the time frames of this project, this will be impossible. In addition, this level of detail and accuracy is not required for developing the high-level vision required by management. We have therefore agreed to have an ongoing dialog with the team members to prioritize their activities and agree when to stop a given activity. Given my experience in putting together presentations for executive boards, this will be one of my key activities going forward.<br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">In conclusion: scope creep is a very common problem for teams carrying out complex projects. However, the effects can be controlled and minimized by using some fairly simple approaches and tools.<br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><br />
</div>Rune Aresvikhttp://www.blogger.com/profile/10439422800800266511noreply@blogger.com0tag:blogger.com,1999:blog-483658600665838321.post-59747333662956316112009-11-14T15:10:00.002+01:002009-11-14T15:10:00.288+01:00Running a Successful Product Development Project<div class="separator" style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none; clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEisjq5WstXHGYoIFQu19JulXnE597hNmA8e3aZ3J038OtmldGLZtvM-2a8neT2gCJYz8rUNMkkaZOeEKYzqUsTvjSmqO45ixs-YlaK02NvYyMEYbf0Rvw-vGf5Vtm6VKblTd9S2RgQhD6_7/s1600-h/23+-+Running+a+Successful+Product+Development+Project.jpg" imageanchor="1" style="clear: left; cssfloat: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" sr="true" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEisjq5WstXHGYoIFQu19JulXnE597hNmA8e3aZ3J038OtmldGLZtvM-2a8neT2gCJYz8rUNMkkaZOeEKYzqUsTvjSmqO45ixs-YlaK02NvYyMEYbf0Rvw-vGf5Vtm6VKblTd9S2RgQhD6_7/s400/23+-+Running+a+Successful+Product+Development+Project.jpg" /></a><br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">In my discussions with executives, innovation, or product development projects, are often given as examples of internal projects that are not successful. When questioned in more detail, usually the "failure" that is being mentioned can be divided into two separate types. The first type of failure is probably the most damaging and frustrating. These failures are usually products that fail in the market place or result in enormous costs and complexity in the production and supply chain process. The second type of failure is less damaging, but probably more frustrating, as it happens more often. This type of failure involves products which are not launched or launched too late.<br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><br />
</div><br />
<div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">In my experience, these two types of failures are caused by two different types of problems. The first type (market failure) is typically caused by the product development project having been structured in the wrong way (hand-overs between departments, wrong type of team, etc). The second type of failure (delay) is typically caused by the team being set up, managed, and run in the wrong way. Given this, how can the success rate for product development projects be improved?<br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">The most crucial response is to ensure that the project is set up and staffed in the right way. Product development projects should avoid hand-overs between departments, and therefore need to include a representative of all key departments involved in the process. This will typically include marketing, production, logistics, account management, etc. The chosen project team then needs to be given the end-to-end responsibility for the successful product launch. This responsibility needs to be collective for the whole team, to ensure that they continue to work together across the whole process. In situations where this methodology leads to teams that are too large, careful thinking should be given to working with core and extended teams, and carefully expanding and changing the team composition across time. An excellent explanation of this is given by Deborah Ancona and Henrik Bresman is their book "<a href="http://knowledge.insead.edu/contents/bresman.cfm">x-teams: how to build teams that lead, innovate, and succeed</a>".<br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">Once the right team has been put in place to carry out the end-to-end innovation process, the next challenge is to make sure that the project is successful. A product development / innovation project will typically score highly on both <a href="http://teambasedconsulting.blogspot.com/2009/07/how-to-identify-projects-that-are-most.html">internal and external complexity</a>, and a very high number of the problems that this type of projects face are likely across all three phases of the typical project. However, these problems can be avoided or minimized by ensuring that key pitfalls are avoided.<br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">In the <a href="http://teambasedconsulting.blogspot.com/2009/09/determining-appropriate-deliverables.html">initiation phase</a> of the product development project, great care should be given to ensuring that the team has a clear understanding of the project goals and the deliverables expected from the project. As mentioned earlier, this should be to deliver everything that will be required for the successful launch of the new product. This will entail that the team must come up with the product itself, the production process, the supply chain process, the marketing process, pricing, etc, etc. Naturally, the team will need to get specialist input on a number of these issues, but the total responsibility must be clearly placed with the innovation team.<br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">The team will typically consist of people who have never worked together and who probably do not know each other. This means that the team should be given help in forming themselves into a team. They need to understand what is required to become a successful team, how it is to work as a team, how they can best make use of each other's skills and capabilities, etc. Finally, the team should be helped / forced to develop a realistic plan for how they are going to achieve their goals and deliverables. They should be made to understand that they will be held accountable for this plan (especially the overall timing and milestones).<br />
</div><br />
<div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">In the <a href="http://teambasedconsulting.blogspot.com/2009/10/determining-appropriate-deliverables.html">work phase</a> key focus areas should include avoiding scope creep, sticking to the agreed milestones, carrying out the required analytics, and communicating with the sponsors and stakeholder. Scope creep is a common problem is this type of projects, as the team is asked to look into related issues, or dives into too much detail on specific issues. To avoid this, a clear process (involving the sponsor) should be put in place to control this. One of the main challenges the team will need to solve (on a continuous basis) is the optimal split between the activities carried out within the team and the use of external experts. When using external experts timing and milestones can become a major problem, as the external experts will not have the same dedication and focus on meeting deadlines. The team should therefore always have a "plan b" for use if the external expert does not deliver (on time).<br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">In the<a href="http://teambasedconsulting.blogspot.com/2009/10/determining-appropriate-deliverables_11.html"> finalization phase</a> the team will need to develop its overall conclusions and the final deliverables. This will typically include the total plan for launching the new product covering all the issues mentioned earlier. In addition, the team will need to develop and carry out a <a href="http://teambasedconsulting.blogspot.com/2009/10/how-to-get-buy-in-for-project.html">communication process</a>. In my experience, this is something that innovation teams often overlook. Their implicit assumption is that the rest of the organization will automatically accept their conclusions and recommendations. Unfortunately, this is often not the case. Therefore the team must carefully consider who the stakeholders are, what their "hot buttons" are, and how they can be convinced to accept the team's conclusions. <br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">It is in the nature of the process that not all innovation projects are successful. However, it is my experience that companies that make use of a structured process as described in this article, have a much higher success rate than other organizations.<br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><br />
</div><br />
<div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">Follow the links if you are interested in more information on <a href="http://www.teambasedconsulting.com/">project planning</a> or <a href="http://www.teambasedconsulting.com/">project management training</a>.<br />
</div>Rune Aresvikhttp://www.blogger.com/profile/10439422800800266511noreply@blogger.com0tag:blogger.com,1999:blog-483658600665838321.post-60366879317421657662009-11-07T08:38:00.000+01:002009-11-07T08:38:00.489+01:00Has Your Project-Team Considered All the Key Dimensions of the Problem?<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjg_N-ACsRIBkNv0F5rzHbHvI-sj1NZZsdCVoEw8-H7POZ5qDEkKzzWmV4ErUE1oxlVeit6oV93hEUqVaBPED-KiQAFqZyd8T-gKV0sSoR2hO_nNhTI_WPEFzXfJtRnZVZ3oOUexvy18MH5/s1600-h/Wordle+-+Has+Your+Project-Team+Considered.dib"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5386421875372334834" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjg_N-ACsRIBkNv0F5rzHbHvI-sj1NZZsdCVoEw8-H7POZ5qDEkKzzWmV4ErUE1oxlVeit6oV93hEUqVaBPED-KiQAFqZyd8T-gKV0sSoR2hO_nNhTI_WPEFzXfJtRnZVZ3oOUexvy18MH5/s320/Wordle+-+Has+Your+Project-Team+Considered.dib" style="cursor: hand; float: left; height: 198px; margin: 0px 10px 10px 0px; width: 320px;" /></a><br />
<div>Many readers have mentioned to me that they feel that a lot of the projects they sponsor (even the successful ones) are often on "automatic pilot". This typically happens once the project teams feel that they understand the problem and have decided on what they believe to be the most appropriate direction for solving the key issues facing the project. The consequences from this can be severe. The most dangerous consequence is often that key aspects of the problem are overlooked. More common is that the team has not analyzed all the relevant dimensions to the problem, and therefore has not developed complete and optimal solutions.<br />
<br />
An example of a similar situation from my own work was a project-team in the insurance sector that was developing a new structure for a company in response to key legislative changes. A key component of the project team's work was to look at the key business drivers for succeeding in the new environment. In a meeting the team presented their key hypotheses, which seemed to make sense. However, a clarifying question was asked about one of the success-drivers suggested by the team, and this lead to a broad discussion in which several new success drivers were identified which the team had not considered. Luckily, this did not happen in the final presentation to a SteerCo, but in a pre-meeting.<br />
<br />
This type of situation can easily be avoided by borrowing a methodology used by consultants called a Blue Team (sometimes it has a different name). The methodology helps ensure that project teams are shaken out of the "automatic pilot mode" and have considered all relevant aspects before the end of the project. This methodology can easily be adapted to internal project teams as well, and is guaranteed to improve the overall quality of the work delivered.<br />
<br />
A Blue Team is a structured meeting typically held once, maybe twice, during a project. In this meeting, the project team gives a short presentation on what it believes to be the key issues (if the meeting is early in the project) or key hypotheses (if the meeting is later in the project). The presentation is given to an invited group of people who are not directly involved in the project. The guest list for the Blue Team should include people with relevant knowledge and experience to the issues being dealt with by the project. Typically the people invited have market knowledge, technical expertise, and/or process experience.<br />
<br />
The invited group needs to be able to quickly understand the issues being discussed, and is meant to be critical in the questions they ask, the comments they give, and the suggestions they make. However, the participants also need to understand that their comments and questions are meant to be helpful to the team. The Blue Team therefore needs to find a balance between criticism and support. One way of achieving this is to clearly state upfront that the process is meant to help the project team, and therefore only the project team can decide how to use the criticisms, ideas, and suggestions coming out of the meeting.<br />
<br />
Even in the best of cases, the Blue Team is tough on the project team, as they (by definition) will get criticism on the work that they have carried out. Given the psychological barriers related to receiving criticism, even a project team with good previous experiences may have to be forced to carry out the Blue Team. My recommendation is therefore to make Blue Teams a standard part of all complex projects that you sponsor, thereby avoiding any choice or discussion on the process.<br />
</div>Rune Aresvikhttp://www.blogger.com/profile/10439422800800266511noreply@blogger.com0tag:blogger.com,1999:blog-483658600665838321.post-27729255754395555782009-10-26T17:37:00.001+01:002009-10-26T17:37:00.669+01:00Using Project Management Offices in Complex Projects<div class="separator" style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none; clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjnbmimG8IT7rQHz0zpTIkSMWN7M8AqhZs4J3s8QQsOO4tF72aBidSx-Fot44vRR61SaR9vOepPmqB5Uw_cmgP85oYeGJv3LPexV9Uyb4ZlVVFXgdGaSo_619PIZe7Z6s6V_bv1ACRekZpr/s1600-h/Using+PMO+in+Complex+Projects.jpg" imageanchor="1" style="clear: left; cssfloat: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjnbmimG8IT7rQHz0zpTIkSMWN7M8AqhZs4J3s8QQsOO4tF72aBidSx-Fot44vRR61SaR9vOepPmqB5Uw_cmgP85oYeGJv3LPexV9Uyb4ZlVVFXgdGaSo_619PIZe7Z6s6V_bv1ACRekZpr/s400/Using+PMO+in+Complex+Projects.jpg" vr="true" /></a><br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">Occasionally I meet potential clients who do not believe that they need external input for making their complex projects more successful. I know that this is hard to believe, but it does happen……………Very often these executives say that they do not need any outside help because they have a Project Management Office (PMO) that fills this role (i.e. making sure that projects run well). This has always bothered me for two reasons. Firstly, I clearly believe that I can offer valuable input to (almost) any organization carrying out complex projects. Secondly, I often see these same organizations outsourcing projects to external consultants, so there are clearly projects that they believe cannot be handled by their internal teams. <br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><br />
</div><br />
<div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">Recently, my thinking on this was brought into focus by an executive from a media company who asked me a slightly different question. He explained that he had mixed results in using people from his PMO in complex projects, and was wondering how he could make best use of them in these situations. There are clearly three alternatives here: 1) Give your PMO total responsibility for this type of projects, 2) make no use of PMO-staff for complex projects, or 3) an intermediate solution.<br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">The cases that I have seen where complex projects have been given to the PMO have generally been a disaster. While Project Management Offices have an important role to play in many organizations, it is important to understand their limitations. In most companies, PMO's have been set up to provide project management for what I call standard projects. These are projects that are closely linked to the core business of the company, and which therefore do not deal with external complexity (openness of goals to interpretation, uncomfortable goals, high degree of communication required) or internal complexity (distance of project from day-to-day business, organizational distance of project participants, sophisticated data collection, and a requirement for "out of the box" thinking). This means that when the PMO uses their "standard" tools on these projects, the results are terrible.<br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">On the other hands, I believe that not using the skills available within the PMO is also a shame, as it is clear that they do have project experience that can be valuable in a wide range of projects. Therefore, the optimal solution is not to give the complex projects to the PMO, but to definitely use the PMO pool of people in staffing the project.<br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">The next question asked by the executive then concerned the role of the PMO-staff in the complex project. Should he use somebody from the PMO as the project leader? In my opinion, this can work, but it is not very likely that this will an optimal choice. Somebody from the PMO will clearly have the required project management skills, but is not likely to score high on other crucial dimensions driving the choice for project leader. These include having sufficient knowledge about the key issues to be covered by the project. Examples of issues where PMO-staff would be unlikely to have sufficient knowledge include a project to look at a new, dramatically different production process, or a strategic pricing project. Somebody from the PMO is also unlikely to have sufficient respect among key stakeholders to be able to "sell" politically difficult conclusions and recommendations.<br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">Using PMO-staff as a participant in a complex project is possible. However, it will not be sufficient if all the person brings to the project are his project management skills. The PMO-staffer will also need to bring some combination of the three skills required of all participants (technical and functional skills directly related to the issues to be solved, analytical skills, and interpersonal skills). If the PMO-staffer has the right combination of these skills for the project, then his additional project management skills can be an asset, and enable him to help the project leader deal with this type of issues.<br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">In conclusion, I would not recommend giving the PMO the responsibility for complex projects. There will also not be many situations where somebody from the PMO is an ideal candidate for leading a complex project. However, using people from the PMO in certain complex projects can be useful, but only if they have additional skills that can be utilized.<br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><br />
</div>Rune Aresvikhttp://www.blogger.com/profile/10439422800800266511noreply@blogger.com0tag:blogger.com,1999:blog-483658600665838321.post-78317791415678934232009-10-16T18:05:00.003+02:002009-10-21T12:16:44.870+02:00How to Get Buy-In for Project Conclusions and Recommendations<div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhD77WX4IwTh1zydMiw-T1EU7zr-q3MxHuTIYCeda0iKbK6sFCOxqzinVdrjQ6wILGnhtPwKEr97C6-zuUerklmlcevddHZmaacu85DB813mkqFd5hmHSl08S4XQEccx7SeQLgiWpTyCQdo/s1600-h/Wordle+-+How+to+Get+Buy-In+for+Project+Conclusions+and+Recommendations.jpg" imageanchor="1" style="clear: left; cssfloat: left; cssfloat: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhD77WX4IwTh1zydMiw-T1EU7zr-q3MxHuTIYCeda0iKbK6sFCOxqzinVdrjQ6wILGnhtPwKEr97C6-zuUerklmlcevddHZmaacu85DB813mkqFd5hmHSl08S4XQEccx7SeQLgiWpTyCQdo/s320/Wordle+-+How+to+Get+Buy-In+for+Project+Conclusions+and+Recommendations.jpg" vr="true" /></a><a href="http://www.blogger.com/"></a>In a recent discussion with a client in the telecoms sector he told me that one of the biggest differences he sees when comparing his internal project teams to the top-notch consulting teams he sometimes uses, is the latter's ability to ensure buy-in for their conclusions and recommendations. His two questions were why the internal teams were not capable of achieving such buy-in, and what could be done about it. <br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">Luckily, there are simple answers to both questions. In my experience, the main reason why internal project teams do not get buy-in for their conclusions and recommendations is that they do not know that a communication process is required. Usually, when I ask the team what went wrong, the answer they give is along the lines of "Nothing went wrong. We carried out the project, and presented the results to the steering committee. What else should we have done?"<br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">This way of looking at the problem is based on a combination of factors. The first factor is related to the scope of the project, as the team has often not been explicitly told that getting buy-in for their conclusions is part of the project deliverable. Secondly, many teams (especially those with a strong technical representation) have a low understanding of the political issues related to their projects. As a consequence, they believe that "the facts will speak for themselves". Thirdly, team members who are not experienced in working on complex projects will typically develop final presentations that focus on the process that the team has followed, rather than the conclusions that they have made. This often means that the conclusions and recommendations are not clearly communicated. Finally, the project team does not usually have any experience in dealing with the group processes that typically take place within a steering committee, nor do they think about also presenting to other stakeholders who may not be represented in the steering committee.<br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">There are three main activities that I tell my clients that need to be carried out to help the project team get the required buy-in and acceptance for project conclusions. The first of these actions needs to take place at the beginning of the project when the sponsor must clearly communicate that the project team bears responsibility for getting the required buy-in and acceptance. The second and third activities by the sponsor takes place at the beginning of the final phase of the project, when the sponsor should force and help the project team to develop a communication plan and must help the team to develop a structured final presentation (using a tool such as the Pyramid Principle). The final point will not be covered in this blog.<br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">When I help teams develop a communication plan, we begin by making an overview of all relevant stakeholders that have an interest in the conclusions and recommendations being developed by the project team. Stakeholders who are expected to be negative towards the results are the most important to identify. For each stakeholder an overview is developed of their "hot buttons" and the dimensions of the solution to which they will need to agree. A detailed plan will then need to be developed outlining how these key issues will be communicated to the individual stakeholders.<br />
</div><br />
<div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">The individual members of the steering committee should also be seen as stakeholders. This means that 1-on-1 meetings are planned with them before the final steering committee presentation. In this individual pre-meeting the SteerCo member have the opportunity to ask specific and detailed questions which then do not have to be raised in the overall meaning. In addition, any specific issues that the SteerCo member has raised in the 1-on-1 meeting can then be addressed in a structured manner in the overall presentation.<br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">Carrying out these fairly simple and straight-forward activities aligns the internal project team with the overall methods used by top-tier consultants, and have resolved most of the issues related to the internal team's ability to get acceptance and buy-in for its conclusions and recommendations in the projects that I have carried out at my clients.<br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;"><br />
</div><div style="border-bottom: medium none; border-left: medium none; border-right: medium none; border-top: medium none;">Follow the links if you are interested in more information on <a href="http://www.teambasedconsulting.com/">project planning</a> or <a href="http://www.teambasedconsulting.com/">project management training</a>.<br />
</div>Rune Aresvikhttp://www.blogger.com/profile/10439422800800266511noreply@blogger.com0tag:blogger.com,1999:blog-483658600665838321.post-46219493454933317782009-10-11T22:27:00.001+02:002009-10-20T11:23:06.431+02:00Determining the Appropriate Deliverables for the Finalization Phase of a Project<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhtHBqjArHu6M5gAZFWOCm4AKTD3qDlcyaBICXP5QZ-RkIn0aUXIWscMfDBE5yKlavrpp6J6JcKcY5Hpje_AZOoavxvUDu5b1D7L8l0RmnzcTDXLi8xtfm37lr_znS4AyFoSHH-QEHybQFZ/s1600-h/Wordle+-+Appropriate+Deliverables+for+Finalization+Phase.jpg"><img alt="" border="0" id="BLOGGER_PHOTO_ID_5384021825966380034" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhtHBqjArHu6M5gAZFWOCm4AKTD3qDlcyaBICXP5QZ-RkIn0aUXIWscMfDBE5yKlavrpp6J6JcKcY5Hpje_AZOoavxvUDu5b1D7L8l0RmnzcTDXLi8xtfm37lr_znS4AyFoSHH-QEHybQFZ/s320/Wordle+-+Appropriate+Deliverables+for+Finalization+Phase.jpg" style="cursor: hand; float: left; height: 157px; margin: 0px 10px 10px 0px; width: 320px;" /></a><br />
<div>In previous blog entries I have suggested what the generic goals and deliverables should be for the first two phases of a complex project. This blog-entry will suggest what the generic goals and deliverables should be for the finalization phase of a complex project. <br />
<br />
When a team enters the finalization phase of a complex project, it typically has carried out most (or all) of the key analytical activities that are required for meeting the specific project goals. The overall success of the team's work in this phase is very much determined by the work that has been carried out in the previous phase. In addition, there is seldom an explicit borderline between the project phase and the finalization phase, as the process can be iterative in nature as insights are developed and final analytical activities are carried out. <br />
<br />
In this final phase, the main goal of the project team will be to develop and communicate the overall deliverables that have been agreed for the project. However, even if the work in the previous phases has been carried out successfully, there are still two aspects that can go seriously wrong in the finalization phase of a complex project: <br />
<br />
- The project team is unable to <a href="http://teambasedconsulting.blogspot.com/2009/09/how-to-help-project-team-develop.html">develop clear-cut conclusions and recommendations</a> based on the work they have carried out<br />
- The team does not <a href="http://teambasedconsulting.blogspot.com/2009/10/how-to-get-buy-in-for-project.html">communicate its findings appropriately</a> (to the right people and in the right way)<br />
<br />
In my experience, complex projects are helped by defining a number of generic deliverables specifically for this phase that are related to avoiding these pitfalls. These generic deliverables will help ensure that the overall goals of the project are met on time and within agreed budgets, and will help ensure that project recommendations are actually implemented.<br />
<br />
<strong>Deliverable Nr. 1</strong>: Clear conclusions and recommendations. This may seem obvious, but one of the most typical problems with internal teams carrying out complex projects is that they do not <a href="http://teambasedconsulting.blogspot.com/2009/09/how-to-help-project-team-develop.html">provide conclusions and recommendations.</a> The requirement that the team must provide clear recommendations needs to be clearly stated at the beginning of the project, but should be re-iterated at the beginning of the finalization phase. This will ensure that the team understands that they are expected to come up with actionable conclusions ("go left" or "go right" not "it is possible to go left or to go right"). The specific deliverable should be a (short) presentation to the sponsor on what the team believes that the conclusions / recommendation coming out of the project are.<br />
<br />
<strong>Deliverable Nr. 2</strong>: A pyramid supporting the conclusions / recommendations. The <a href="http://www.barbaraminto.com/">Pyramid Principle</a> is a tool used by consultants to force the project team to develop a logical supportive structure for their conclusions. The basic methodology is well-defined and easy to learn. Developing a pyramid will serve both as a logical test of the conclusion / recommendation (do the results of our analysis support what we want to say?), as well as providing an excellent starting point for developing presentation and reports for the communication process. The pyramid can be tested with the sponsor at the same meeting as the suggested conclusions and recommendations.<br />
<br />
<strong>Deliverable Nr. 3</strong>: A communication plan. Most internal project teams only work toward a final presentation to the steering committee. This often leads to problems because presenting new material to a steering committee often leads to surprises and unwillingness from the steering committee in accepting the conclusions and recommendations. A <a href="http://teambasedconsulting.blogspot.com/2009/08/how-to-ensure-that-key-stakeholders-are.html">process </a>should be put in place that allows the individual members of the steering committee to see the final presentation individually before the final presentation so that they can give their opinions, and ask their specific questions. In addition to the steering committee there are usually also <a href="http://teambasedconsulting.blogspot.com/2009/08/how-to-ensure-that-key-stakeholders-are.html">other stake-holders to need to be informed</a> in order to ensure buy-in and implementation.<br />
<br />
If you can honestly say at the beginning of the finalization phase of your project that all of these generic deliverables will be developed, then the project has greatly enhanced its chances of successfully reaching its overall goals in such a way that the conclusions and recommendations will be accepted and implemented.<br />
<br />
Follow the links if you are interested in more information on project planning or project management training.<br />
<br />
<br />
</div>Rune Aresvikhttp://www.blogger.com/profile/10439422800800266511noreply@blogger.com0