[ictgov] Fwd comments from Peter Dore on Project Governance

Tue Nov 14 14:55:42 EST 2006

Hi Peter,

Perhaps the concept that is missing is Risk and its management.

 From AS8015 (& 4360) -
available at 
<http://www.saiglobal.com/shop/script/Details.asp?DocN=AS073376438XAT>

Risk: The chance of something happening that will have an impact upon 
objectives. It is measured in terms of consequence and likelihood 
(AS/NZS 4360)

Changes in deliverables/scope need to be balanced against objectives... 
they could fall short or exceed initial understanding and expectations - 
due to developments in the project or external to it...this is business 
alignment.

Marghanita
<snip>
> From:
> Peter Dore <pdore at emirates.net.ae>
> Date:
> Sat, 11 Nov 2006 22:33:42 +0400
> To:
> 'Tom Cleary' <tcleary2 at csc.com.au>, 'Rimas Skeivys' 
> <rimas at ugovern.com.au>, 'Marghanita da Cruz' <marghanita at ramin.com.au>
> 
> 
> Hi all,
> 
> (Firstly, please note new email.  pdore at eim.ae <mailto:pdore at eim.ae> I 
> can receive on the old optusnet address however cannot send on it. I 
> prefer you send mail to both addresses)
> 
> I'd like to add some experiences in to this part of the conversation. I 
> have had the role of implementing full SDLC/PM/QA/etc methods and 
> processes into a couple of reasonable sized places. I was heavily 
> involved in BHP IT a few years ago in Canberra and corporately as 
> Corporate PI Manager, and then in a major Saudi Bank where I inherited a 
> very large number of half baked projects including some very major items 
> to sort out. Add to this my background in Naval engineering and major 
> repair projects for warships which is a bonus because of the required 
> high discipline levels in PM....
> 
>  From this experience I will add some comments to Tom's below, marked 
> with [PD*** ]
> 
> <<snip>>
> 
> My observations lead me to believe that there are some drawbacks to 
> Project Management models which only seem to get discovered when things 
> go too far to avoid additional cost/downtime or other pain.
> 
> Meeting User requirements under the strictures of a Sponsor is an 
> excellent objective.
> 
> However, everyone knows that scope creep tends to boil away budget which 
> should be used for some of the "quality" functions ( documentation, 
> anyone? ;-) and I think that means we often do not address the whole 
> story, leaving some issues to the Business to deal with by other means.
> 
> [PD*** One of the, if not the actual, worst managed areas in PM today is 
> Requirements. Scope creep is a basic PM skill and is a joint 
> Requirements Management / Configuration Management / Management 
> Discipline issue. In order to adequately control the budget we need to 
> be very careful to avoid scope creep - easily said, however many 
> customers and in my recent Qld experience even project directors will 
> all too readily add scope and no budget with lame excuses like 'it's 
> always there, but we didn't see it before'..... Etc. By ensuring that 
> scope items (individual requirements) are carefully identified and 
> placed into CM and under change control, then justification has to be 
> made, including added budget or offset, or the scope cannot change. This 
> is basic and must be placed into project procedures. PRINCE2 adequately 
> addresses this in it's CM words, but rarely do we see the discipline 
> applied to make it work. PRINCE2 requires discipline, and the trainers 
> will tell you this..... Like I mentioned, easily said, but the 
> importance is usually seem too late.]
> 
> In my experience, this means that instead of using a wide range of 
> knowledgeable resources to go looking for issues when reviews occur, 
> people tend to get sign off from the Architect, the User rep. and 
> Sponsor, then submit the forms for cutover to production ( ... I know, 
> ITIL does have the whole "Release Mgmt" thing in this space )
> 
> Don't get me wrong, the Project is properly constituted and maintained 
> and does not suffer from any unusual stresses that would not be part of 
> normal running, so the Management decisions get properly made and approved.
> 
> [PD*** This is one area I would question. I cannot agree the project is 
> properly constituted and maintained when the need for careful 
> requirements control is not maintained and scope creep erodes the budget 
> to a significant extent. My experience is similar, but my interpretation 
> is that a lack of suitable discipline to properly implement the methods 
> and processes is the cause.]
> 
> But because the Architect, Users, Sponsors and Project Managers are 
> focused on the Project itself, often without full knowledge of other 
> Projects, Infrastructure developments or Technology changes, significant 
> issues may arise unseen. ( The guy who taught me PRINCE told me of 
> "OSINTOTS" == "Oh s**t I never thought of that." - like gremlins )
> 
> At that point, it is often discovered that the app. is going to produce 
> security problems/network overload/third party costs/whatever which are 
> then fudged around because it's too late to fix the problem and the 
> project must go live, or it is "out of scope" so the Business has to 
> address it in some other way - often by accepting high risks or facing 
> the political damage from having a project fail "in public".
> 
>  
> 
> [PD*** The Architect, Users, Sponsors and PMs do focus on their 
> projects, but as Tom says so often this is to the detriment of other 
> projects and again, the area of Portfolio Management, or perhaps we can 
> call it Programme Management, should be instituted to cover this. 
> Governance has a real role here and I will come to that later. My 
> approach in the Saudi Bank was to critically examine the 93 projects I 
> inherited. Many were small and insignificant, many were pet and unfunded 
> jobs, some were critical and others in the middle. My instruction was to 
> 'implement PRINCE2' as if that was the way to fix the mess. First I 
> built 6 programmes of related projects (the Electronic Banking Program, 
> the Treasury Programme, etc) and I managed to have clear project 
> managers defined for each project. Then made a clear definition of 
> Programme Managers for each programme. I trained the Programme Managers 
> in the same way as the project managers, and had them produce program 
> plans that looked like project plans, but their project was to manage 
> the project managers and project interdependencies..... (By project 
> plan, I mean Project Management plan, not a MSProject schedule). Then I 
> advised the PMO manager to build a similar PMP for the overall 
> portfolio, and I purchased a HP A0 plotter so that we could get full 
> programme timelines on the one sheet, and show inter project, intra 
> programme, and inter programme dependencies all together. This is 
> complex, but I am cursed with the ability to see the big picture so it 
> had to be communicated to each project and programme manager, to the PMO 
> and ultimately to the sponsors and the Board of the bank so that all 
> could see the risks and effects of decisions across the full suite of 
> work. In this way the necessary compromises that come into all PM work 
> can be optimised to reduce cost and schedule overrun. Ultimately the 
> projects started to come in closer to schedule and budget, but the cost 
> is a lot of work.
> 
> So I implemented PRINCE2 as instructed, tailored with guidance to suit 
> the varying sized projects, supported by a higher level version to 
> manage the programmes in the same manner as the projects, but not quite 
> as it had been seen before or expected, and somehow kept my sanity (I 
> think). My sponsor was the CEO of the bank which provided support to get 
> the initiatives actually in place.]
> 
> [PD*** Now to the Governance side of all this. In the back of the mind 
> we need to retain the lessons of our failures, and of our successes, and 
> ensure that our Governance adequately addresses them. I see a prime role 
> of Governance, if not THE prime role, is to objectively verify that all 
> the precautions to do with the use of proven methods and processes, and 
> management discipline are in place and used, and that short-cutting or 
> reduced management is only allowed when the risks and consequences of 
> the approach is adequately considered. Governance must ensure that 
> method and process tailoring to suit project size and complexity is 
> appropriate and that adequate dependency management is carried out at 
> the appropriate level.
> 
> This is one of the reasons that I was unhappy with guidance in our 
> Governance standards where we provided a set of closed questions easily 
> answered by saying 'Yes', instead of being answered with adequate 
> analysis to provide actual information. I piloted those closed questions 
> and was very unhappy with senior Government response as it failed to 
> give real information to the effectiveness of the PM or the governance 
> being implemented.
> 
> My apologies for my extended reply, but I hope this provides some 
> thought material.]
> 
> Regards
> 
> Peter Dore
> 
>  
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> ICT Governance Forum 
> http://listserv.csu.edu.au/mailman/listinfo/ictgov

-- 
Marghanita da Cruz
Phone: 0414-869202
http://www.ramin.com.au/itgovernance
http://www.ramin.com.au/linux
http://www.ramin.com.au/eco-sydney