bpc consulting, inc. march 2013 identifying, avoiding and rescuing troubled it projects: an...

BPC Consulting, Inc.March 2013

Identifying, Avoiding and Rescuing Troubled IT

Projects: An Executive Manager’s

Discussion

2BPC Consulting, Inc

C2013 All Rights Reserved

Discussion Introduction

• In talking about troubled or failed projects, it’s funny but true, that

if you think you’ve got a problem, then you probably do.

• The degree of complexity inherent in modern integrated utility and

governmental systems can easily swamp your organization’s

capability to plan, organize and implement such systems.

• Because of this you are more and more dependent upon the

expertise, reliability and professionalism of your advisors,

consultants and vendors. But they often have different, conflicting

goals and responsibilities.



Discussion Purpose

• We have developed this “Discussion” as a quick

introduction into how we at BPC Consulting, Inc work

in assessing and resolving “Troubled Projects”.



In the beginning:

We had great expectations.

Regretfully, our planning, work effort and follow-through wasn’t as well thought out……



“Troubled” Projects: BPC Consulting, Inc. Approach to Identification and Resolution

Identifying the Classic Symptoms of “Troubled” Projects on your project; how bad off are you right now?

Determine the source(s) and severity of your problem(s)

Not overreacting to typical project challenges

Building a solution to you problem (s): One that doesn’t involve shooting the survivors (building

solutions not slings and arrows)

Getting the right team on your project: Creating a winning team and executive management model

Creating an Achievable Project Plan



What Classic Symptoms of a Failing Project Do You Have?

• Progressively later projects reports to management• Most reported issues remain unresolved from project report to project report• Reported issues disappear from project reports without a corresponding reporting of

its resolution• Project reports show no issues or problems and/or the reports are almost identical

each month• Reports of “version control” issue surface late into the project• The project has had more than three project managers• The testing plan and/or program is still to be developed/completed within 6 months

or less of the scheduled go-live date• The user training plan and/or program is still to be developed within 6 months of the

scheduled go-live date• There has been more than one change in the vendor and/or consultant project

manager• There have been more than 2 changes in the official go-live date• You are asked or told by your consultant or vendor (or, heaven forbid, your own

staff) in response to your legitimate questions to:•Trust them•Take a leap of faith•Have faith in the project’s success



The Failure Development Chain: What’s Gone Wrong?

Thoughtful/Detailed Project Planning:•Does the project Design/Architecture reflects what’s needed and useful, not just a wish list?•Can a vendor supplied system do what you need?•Do you have a fully engaged and capable Project Manager? How up to date and accurate are the detailed project plans?•Can you document what you want/need? As-Is/To-Be’s•Change Management Planning?•Detailed Test Planning?•Are Project/Program meetings a meaningful exchange of information and discussion of the Project/Program or just a brief cursory update?




Data:•Are you trying to use point-to-point system interfaces when middleware needs to be used to share and send data?•Do you have a documented data model/dictionary?•Are there well-developed and fully tested conversion plan/programs?•Is there a plan for follow-through to maintain concurrency of data post conversion?•Is data the responsibility of any single group/person?•Are there ‘real’ plans for data testing?




System Integration:•Are you trying to use point-to-point system interfaces when middleware needs to be used to share and send data?•Do you have a documented data model/dictionary?•What is the relationship between your System Integrator and your other Project/Program members?




Third Party Software:•Are users sidetracking the project by insisting that the “new” system work just like the “old” system•Are Project Managers holding the line on system changes versus user process changes?•Are you taking advantage of real opportunities for Business process Reengineering with the new systems?




System Set-up/Conversion:•Are users heavily represented in these teams?•Is there a User headed team responsible for Monitoring and Reporting System and User Issues?•Are users complaining that less and less is being delivered in the initial system roll-out?




Training:•How does this new system (s) change your technical IT operations? Is there planned IT training?•Are Training needs to have the fulltime focus of a training group/team?•Have Training needs been planned to cover the conversion period, new operations and newly hired staff?•Have Back-fill of staff in training been planned?•Will training be on the system as implemented?




Testing:•Is middleware used to share and send data?Are there a well-developed and fully tested conversion plan/programs?•Is there a plan for follow-through to maintain concurrency of data post conversion?•Is data the responsibility of any single group/person?•Is the work for developing the Plans for data testing underway or deferred?




User Guides and Procedures:•Did someone get the responsibility for the development of user training and procedure documents at the tail-end of the Project?•Is the development of user procedures and training materials the sole responsibility of each system vendor and mostly based upon off-the-shelf documentation?




Post Implementation Support/Training:•Who actually knows how to run this system from start to finish? What was this supposed to do?•Do you have a single point-of-contact, internally, for maintaining and supporting this new system?•How is the software change management planned?



Do you have the right team, rational and achievable goals and the right planning for this project? Are there fundamental changes that need to be made in the Project/Program?

Is the project ‘owned’ by user's or the IT Group?

Does the project have specific identified goals and objectives? Do these match the organization’s Strategic Planning?

Is there a detailed cost estimate and timeline? Are all costs included, including training, testing, backfill of staff, etc?

Is there a consensus of users that this is a needed project?

What are the critical project assumptions and risks?

What is the problem that’s being addressed/solved?

Is this the first time your organization has addressed this problem?

Where else has this solution been implemented?

Can your project team clearly define where you are now and what the new system will do when completed?

Can this project be accomplished in smaller project elements with much lesser risks?



Approach to the Solution

• Don’t underestimate the complexity of state-of-the-art integrated business and operational systems

• Don’t accept plans that assume implementation faster than industry norms

• Seek out and embrace best practices (but not today’s fad)

• Work within the limitations of quality vendor supplied software solutions

• If the software has to be highly modified, either buy different software, or re-do your business or operational processes (Change Management is critical to success)

• Create a justifiable business value framework for ALL major projects; insist that the Project/Program meet identified KPI’s and Business Case values

• Insist that top management be involved and engaged• Don’t be “rushed” into a Solution



Build A Framework for Success

• Spend the extra time needed in contracts development with vendors, consultants, and developers to ensure that they deliver, on a mutually verifiable basis, what you want and need (Involve attorney’s that know and understand systems technology)

• Ensure that all contracts have specific timelines and deliverables (provide rewards and penalties)

• Maintain a Project Management Office (PMO) Function throughout the project’s life

• Develop and follow a detailed implementation plan and tactics (modify as needed, but DO NOT abandon)

• Create an engaged and involved Steering Committee• Present status and issues to Executive Management

on a regular basis• Require your PMO staff to regularly report on the

Project’s performance• Ensure that your PMO is independent from your

Project staff



Crafting a Turn-Around Solution

• Don’t manage by exception• Ensure that all major complex projects

have an independent, external PMO group

• Insist that the Project Plans and Budgets be re-published Monthly based upon actual results

• Insist that the project “Owners” be fully involved throughout

• Don’t be afraid to stop and re-think a failing project

• Insist that Bad News be reported FIRST• Attend scheduled meetings, and be-

prepared



Thank You

bpc consulting, inc. march 2013 identifying, avoiding and rescuing troubled it projects: an...

Documents