Subject Project Management Assignment 3

Subject: Project ManagementAssignment 3Question - “A case history of a project in which the author has been a participant, outlining: the processes it followed; the issues that arose and how they were resolved, and the lessons learned. On what basis would you determine the success or failure of this project?”M A WilliamsI declare that this assignment is based on my own work and that all material previously written or published in any source by any other person has been duly acknowledged in the assignment.(Signed)………………………………………….M A WilliamsAbstractThis paper looks at the processes, issues and lessons learned from the implementation of a global web and intranet into a large financial services organisation. During this project, the author’s role was as a project manager responsible for discrete projects, as well as being part of the team which addressed the necessary organisational changes brought about by the project. The paper concludes with a review as to whether the project could reasonably be determined a success or failure.1. Outline of projectThe project objective was the implementation of a global web and intranet into a large financial services organisation, with approximately 1,800 employees located over sites across the world. The Head Office was based in the UK, but the organisation had more than 50% of its staff in Australia, and across 15 plus further offices in Continental Europe, North America, and South East Asia. There were strategic plans to further expand the operations of the firm in European and Asian markets.The organisation’s strategic direction was towards becoming a truly global business, and the implementation of a global web and intranet project on which this paper is based was a significant part of this overarching strategy. It involved the design, development and implementation of web presences for internal and external audiences. These new environments were to provide the organisation with a marketing presence for clients and partners on the internet, and, more critically, create a global intranet to facilitate communication and information sharing between staff centres across all regions and offices.The emphasis of investment and effort on the project was heavily biased towards the intranet element, as the scope for using the internet as a medium for the selling of institutional funds management services was even at the outset of the project recognised as extremely limited. The emphasis on the intranet element also reflecting the high value which the organisation placed upon its own intellectual property, and its desire to harness and capitalise on that value across international and functional frontiers.However, the success of the intranet project, and therefore the project as a whole, depended as much upon the desire of individuals within the organisation being willing to share their ideas outside of their functional, regional or national cells, as it did upon the successful provision of tools facilitating their doing so. Such a desire would represent a major cultural shift within an organisation where the cult of individual was strong.The author’s role was as a project manager responsible for discrete projects, as well as being part of the team which endeavoured to address the necessary cultural shift towards knowledge sharing.2. The processes followedThe project was jointly resourced by employees of the organisation who were seconded to the project, and management consultants from one of the large management consulting firms. The teams were completely integrated and followed the project management methodology of the consulting firm. This methodology was similar in many respects to the standard approach put forward by the Project Management Institute in its Guide to the Project Management Body of Knowledge.1 Where it differed was in detail (forms, schedules) and emphasis (change management was a significant workstream on the project).The project was run on an 18 month change programme with a series of staged releases (three in total) planned. The initial plan was to break the project up into three key releases:•Release 1 – Foundation of a global network, global web presence, and intranet, featuring static content and simple interactive functionality to targeted audiences •Release 2 – More sophisticated interactive functionality within the intranet product and greater depth and breadth of implementation across business units and regional centres•Release 3 – Full interactive and integrated functionality extensively implemented across the organisation as a wholeThese releases corresponded to the three-phase approach adopted by the project’s management: “Think Big; Start Small/Smart; and Scale Rapidly”. Each release wasto run over a period of 90 – 120 days to enable the rapid delivery of business needs, and running through each of the phases was a project management, change management and communication programme.Releases 1 and 2 where both achieved on target. However, at about the time Release 3 was being planned, global financial markets took a downturn and funding for the project was drastically cut. This affected the approach adopted by the project, and led to swingeing cuts being made to the project’s budget (particularly in the change management workstream). Thereafter, emphasis was placed on a series of small rolling releases as the project transitioned in Business As Usual.Included in the project was the use of ePMO (electronic Project Management Office), a tool designed to facilitate document sharing and collaboration amongst the global team. It was to provide:•Information (Newsletters, training & workshops)•Project Management (schedule, project plan etc)•Communications•Resource management (Utilisation, procedures)•Financial planning (budget analysis)•Issues and Risk Management (Escalation & resolution)3. Issues resolutionThe process adopted by the project for issues resolution was for issues to be raised orally at a weekly global meeting. They were added to the issues list and were monitored at future meetings.In the IT Toolkits article “Don’t leave project status to chance”2 the importance of behavioural factors which influence the reporting process is noted. The author would concur with this as a major influencing factor on the project with project managers always keen to report good news on their projects with not all being willing to raise issues in a global meeting. However, to mitigate the effects of this, written status1 Project Management Institute, A Guide to the Project Management Body of Knowledge, 2000 Edition, Project Management Insatiate2 Author unknown, Don’t leave project status to chance, May 2000, quoted in the ACS Certification Program Study Guidereports were required on a weekly basis which had to classify the projects into one of three stages:•Red – significant issues affecting progress•Amber – issues arising that are likely to affect key deliverables•Green – on targetAny projects with a red or amber status were automatically tabled for discussion at the global meeting. This had the effect of combining reporting methods to provide a blend of meetings and written status reports – one of the recommendations of the IT Toolkits article.The management of risks and the resolution of issues that did arise on the project was a key part of the management process. Unlike US based projects3 the programme office did not have the luxury of insuring against risks by taking out liability insurance to hedge against the occurrence of major issues. Instead risks were monitored on a risk log – any new risk was logged onto the schedule. Once logged on the schedule the risks where categorised according to magnitude and likelihood (high, medium and low). Responsibility for risk mitigation and review was allocated to a team member and progress was regularly monitored at the global meetings.4. Lessons learned4.1 Project Implementation ReviewTo the best of the author’s knowledge no formal post- project implementation review (PIR) was undertaken although many of the individual project managers (the author included) undertook individual reviews on their particular projects. This is in line with anecdotal evidence which suggests that few organisations undertake PIRs4. Cost may have been a factor as research has shown that a PIR can cost upto 10% of the systems original cost5. At the time the project was transferring to Business As Usual (BAU), the financial markets were experiencing a significant downturn and funding for new enhancements (or PIR’s) was limited. In any case the changing project requirements – much had changed in the organisation since the project had been3 Lauren Gibbons Paul, Risk Management, Highwire Acts, June 1998, , quoted in the ACS Certification Program Study Guide4 Grant Butler, Post-natal dissection, February 2001, , quoted in the ACS Certification Program Study Guide5 Grant Butler, Post-natal dissection, February 2001, , quoted in the ACS Certification Program Study Guideinitiated and the project had changed as a result – would have made any review against the initial business case difficult.4.2 Lessons Learned – What Went WellIn the authors experience, IT project managers traditionally focus on the hard skills skills (structured management processes) rather than the soft skills (interpersonal skills such as communication). This view is supported by the work of Robert Butterick whose book The Interactive Project Workout6, focuses mainly on the softer skills required to successfully deliver projects.This is further supported by Keil et al in their article “A framework for identifying software project risks”7 which identifies the key risks associated with projects. In line with Butterick’s view that there should be a greater focus on the softer skills, only one of the 11 risk factors identified by the participants in the study involved a hard skill (the introduction of new technology), the others were seen as more “soft” – the top three were:•Lack of top management commitment to the project•Failure to gain user commitment•Misunderstanding the requirementsThe project initially performed well against this set of criteria, as shown below.4.2.1 Top management commitmentIn the authors view none of the key risks outlined by Keil et al were a major issue for the project under review. This is particularly the case for the issue of sponsorship, where there was a high degree of top management commitment - the CEO acted as Project Sponsor and frequently espoused the benefits of the project at management meetings and group forums.4.2.2 User commitmentPartly as a result of the high level of sponsorship there was strong user commitment. This was harnessed by the project team through the development of a user group known as the eBusiness Champions. These were senior employees who were6 Robert Buttrick, The Interactive Project Workout, Second edition 2000, Pearson Educationselected to be project champions within their business units, providing other users with up to date information on the progress of the project and giving the project a tangible profile amongst the user community.4.2.3 Misunderstanding the requirementsThe eBusiness Champions where also responsible for helping gather business requirements (for Phases 2 & 3), ensuring that the project team was able to fully understand and prioritise user requirements.4.3 Lessons Learned – What to leave behindIn their article, Keil et al go on to explore other issues which the authors believe had an influence on the project, most noticeably the failure to manage end user expectations. Although top management was committed to the project goals, and communications were initially carefully managed, budget cuts in the change management workstream in the later stages of the project’s life meant thatthere was a lack of communication surrounding some of the key deliverables, resulting in some of the project’s proponents becoming disenchanted.The eBusiness champions / end users had been closely involved in the requirements gathering process but as Weinberg states in his article It’s the expectations, stupid “Requirements ain’t expectations”8. As the budget for the change management programme was cut, information was no longer passed to the business in a streamlined fashion and just as the project began to focus on business benefits and creative solutions for individual business units so the project’s management of overall expectations failed to deliver.In the author’s view, change management could be seen as the single most important factor in managing user expectations. Although a programme of change was initiated it was never fully implemented and the handover to the business at the conclusion of the project (Business As Usual) was only partially completed. Research has shown that IT projects rarely place sufficient resources and emphasis on the people issues9. This is not the case in the early stages of the project under7 Keil et al, A framework for identifying software project risks, November 1998, Communications of the ACM, quoted in the ACS Certification Program Study Guide8 Gerry Weinberg, It’s the expectations, stupid, July 1997, .au, quoted in the ACS Certification Program Study Guide9 Richard T Houston, The human side of IT, July 2000, , quoted in the ACS Certification Program Study Guidereview where significant resources were devoted to the change issues inherent in the project. Unfortunately, due to falls in the financial markets and subsequent budget cutbacks, much of the emphasis on change management occurred in the early stages of the project, when user perception was that relatively little was being delivered (in actual fact a mistaken view, this being a period when global infrastructure was being installed, and core applications developed, upon which future applications depended).In their paper “An integrated framework for managing change in the new competitive landscape” (Prastacos et al, 2001)10, the authors outline an approach for managing change in the new competitive landscape. The paper provides an integrated framework for approaching organisational change and provides a useful basis for examining why the change management process broke down on this project. The Prastacos paper draws on many existing models and concepts that attempt to provide a framework for the management of change.The programme described above followed the majority of the precepts of Prastacoes et al, in principle at least. However, some important areas were neglected, or badly managed, generally as a consequence of the circumstances in which the senior management of the programme found themselves. For instance, the programme was required to build a global network infrastructure, scope and implement a host of applications which were to sit upon it, and develop the control mechanisms which would govern its management once it had been integrated into the business, all in an extremely short timeframe. Achieving these goals required an autocratic management style, which resulted in communication being poorly managed, even in the project team itself. Also, aspects of business handover were not managed as thoroughly as they ought to have been.Another external influence which could not have been anticipated was the global markets downturn. This resulted in a need for significant cost saving, and meant that the integrated framework of change management which was planned could not be implemented once the project was up and running, and the need for the technology outputs of the project becoming embedded within the organisation was at its greatest.10 Prastacos et al , An integrated framework for managing change in the new competitive landscape, 2001Whatever the reasons for its non-implementation, the programme highlights the critical importance of following through programmes of change management once the technological aspects of the programme have been implemented.4.4 Lessons Learned – the authors viewOther lessons which the author’s own Post Implementation Review identified and which might be applied to the programme as a whole included:•The use of the project management tool: ePMO•Meeting fatigue•Benefits realisation•Group planning sessionsThese are explored in more detail below.4.4.1 ePMOA key lesson was the use of the web based project management tool ePMO. As outlined above, this was to have provided significant benefits to the project in terms of global accessibility to information. Indeed, George Sifri, in his article “Web-Based Project Management11, states that “web based project management is the key to successful project management in today’s global business environment.” However there were significant issues with the tool adopted for use by the project team members, which was poorly designed and compromised by significant bugs. Far from facilitating communication, it actually made global communication difficult, leading to mis-understandings and misinformation which took time and effort to correct. However, the main reason for the ePMO’s lack of effective use was a result of performance issues experience by project team members when overseas. This had a knock-on effect with problems identified by Sifri in the above article: •Refusal to use the system – stemming in part from a lack of confidence in the tool due to performance problems experienced by teams overseas•Difficult to use interface – although not overly user friendly the interface issues could have been overcome with increased user involvement in the setting up of the tool and more in-depth user training. However, the major contributory fact were the performance issues outlined above11 George Sifri, Web-Based Project Management, Working Side-by-Side Worldwide, August 2000, , quoted in the ACS Certification Program Study Guide•Resistance from different types of users – some users were reluctant to share information with the external consultants and would not therefore update theePMO with relevant information. This could have been overcome with effective change management processes had the performance issues not played such a major role in discrediting the tool.4.4.2 Meeting fatigueThe global nature of the project meant that managing communication on a global level was impaired by the time differences of the different locations. In order to effectively manage communication the programme was broken into two regions: •Northern Hemisphere – UK and North America•Southern Hemisphere – Australia and New ZealandRegular weekly meetings were held between the UK and Australia with updates provided to the North American and New Zealand teams by the relevant geographies. This was further complicated in Phase 2 of the project when Hong Kong, Singapore and Japan came on-line. As such there was no single time which all geographies could reasonably be expected to be represented at the “global” meetings. This led to a proliferation of additional meetings in order to keep team members upto date with the latest key decisions and progress reports.The meetings themselves generally followed best practice procedure12 which included: keeping time schedules; providing agendas and follow up minutes (objectives and outcomes); accountability for outcomes – although unlike Sandy Damashek’s advocacy of “Koosh balls and silly putty”13 no toys ever appeared in the meeting rooms!4.4.3 Benefits realisationDeveloping a benefits realisation register for each of the projects was critical to being able to monitor the success or otherwise of the implementation. However, many of the projects did not undertake a critical analysis of the benefits realised at the conclusion of the projects.12 Christopher M Avery, Guides to Great Meetings, February 2001, , quoted in the ACS Certification Program Study Guide13 Sandy Damashek, Koosh Balls and Silly Putty, February 2001, , quoted in the ACS Certification Program Study Guide4.4.4 Group planning sessionsWhen creating the project plans for the individual projects on which the author worked it was apparent that those with the most accurate plans were the result of a collaborative approach to project planning. This is in-line with best practice advice14 which advocates avoiding single person estimates.5. Two years on: success or failure?In their article Looking back, Looking ahead, Karl Weigers and Johanna Rothman explore how an examination of the last project can improve the next one.15 As shown from the above, there are many lessons too be learned from the case study under reivew. However, in trying to gauge the success or otherwise of the project it is important to review the substantial benefits brought about from the implementation of the global web and intranet. Today much of the functionality provided by the system seems commonplace and without the structured approach of the formal Post Implementation Review and the revisiting of the business benefits it is sometimes difficult to remember quite how far the organisation has come towards its original objectives.In his article Project Termination Doesn’t Equal Project failure16 Boehm explores the reasons for project “failure” or closure. In the case study under review the organisation has substantially reviewed its strategic objectives and is in fact de-merging its operations back into regional divisions. As a consequence, the requirement for a global network is no longer appropriate. Does this mean the project was a failure? The author thinks not, as it met its strategic objectives and although more could have been done to drive the change home and increase the overall business benefits, its sponsors and management could in no way have foreseen the changes that have lead to its termination.14 ACS Certification Program Study Guide, PM1 Module 7 Time Management, ACS 200115 Wiegers and Rothman Looking Back, Looking Ahead February 2001 quoted in the ACS Certification Program Study Guide16 Boehm, Project termination doesn’t equal project failure, September 2000, Computer, quoted in the ACS Certification Program Study GuideAppendix 1Bibliography1. Project Management Institute, A Guide to the Project Management Body ofKnowledge, 2000 Edition, Project Management Insatiate2. Author unknown, Don’t leave project status to chance, May 2000, quoted in theACS Certification Program Study Guide3. Lauren Gibbons Paul, Risk Management, Highwire Acts, June 1998,, quoted in the ACS Certification Program Study Guide4. Grant Butler, Post-natal dissection, February 2001, , quoted inthe ACS Certification Program Study Guide5. Grant Butler, Post-natal dissection, February 2001, , quoted inthe ACS Certification Program Study Guide6. Robert Buttrick, The Interactive Project Workout, Second edition 2000, PearsonEducation7. Keil et al, A framework for identifying software project risks, November 1998,Communications of the ACM, quoted in the ACS Certification Program StudyGuide8. Gerry Weinberg, It’s the expectations, stupid, July 1997, .au,quoted in the ACS Certification Program Study Guide9. Richard T Houston, The human side of IT, July 2000, , quotedin the ACS Certification Program Study Guide10. Prastacos et al , An integrated framework for managing change in the newcompetitive landscape, 200111. George Sifri, Web-Based Project Management, Working Side-by-Side Worldwide,August 2000, , quoted in the ACS Certification Program Study Guide12. Christopher M Avery, Guides to Great Meetings, February 2001, ,quoted in the ACS Certification Program Study Guide13. Sandy Damashek, Koosh Balls and Silly Putty, February 2001,, quoted in the ACS Certification Program Study Guide14. ACS Certification Program Study Guide, PM1 Module 7 Time Management, ACS200115. Wiegers and Rothman Looking Back, Looking Ahead February 2001 quoted in the ACS Certification Program Study Guide 16. Boehm, Project termination doesn’t equal project failure, September 2000,Computer, quoted in the ACS Certification Program Study Guide。