PRIORITIZING AND SELECTING IT PROJECTS

http://www.cio.com/article/486284/10_Famo us_ERP_Disasters_Dustups_and_Disappointm ents http://www.crmblogguy.com/crmfailure.htm

~60% of all ERP implementations fail ~47% of CRM implementations fail (Forrester Research)

Most Enterprise Software Implementations Fail: ERP, CRM, SCM, BI

Most IT Projects (will) fail

1. Failure to assess risk (or acknowledge) the implementation risk of a project at the time it is funded 2. Failure to consider the aggregate implementation risk of a portfolio of projects 3. Failure to recognize that different projects require different managerial approaches (Ex. Do not choose someone who dresses well and speaks reasonably good English as your Project Manager all the time)

End to End Project Management

Technology Impact Assessment Consulting
Current System Study (As Is Process, Infra) Business Process Definition (To Be Process, infra) Customization

Localization

UAT

Roll out

End User Support

End to End Project Management

Things dont work out despite frameworks

Short term view
Lets get this done quickly

Technology short cuts

Unclear understanding of technology environment Not interested in long term sustenance of IT

Business shortcuts
Want to look good fast Inadequate detailing of business requirements

People involvement short cuts

Wrong skills deployed What do they want? Never asked. Top down push of IT

Poor change management strategy

Where is the rallying cry? Poor to inadequate user education

Organizational Dynamics
Pressure to meet ST targets
Declining performance

No time for thinking through strategy

overload

No decisions

Overload-fall in productivity-performance degrades-no time for maintenance/training-overload

Exercise: Overload at the Individual Level

Pick an aspect of your life that feels overloaded. Can you trace the effect on your performance? What are the underlying causes of this overload? What interventions can you see to get unstuck?

When performance is low what do managers do?

The Fundamental Attribution Error)
Much research suggests that in the situations we study, people are predisposed towards blaming problems on other people rather than on the systems in which they live and work

And, if managers make the FAE how do they respond?

More production pressure More oversight
I knew my project was in trouble when I had to give hourly updates

What happens next?

If managers respond with more oversight and more production pressure what feedback do they get? In the short run. In the long run

The Self Confirming attribution error

When managers make the FAE, their subsequent interventions provide feedback confirming their initial attribution More Production Pressure: Leads to a short term improvement as people focus on production at the expense of capability Leads to a long run degradation as capability declines More Oversight: Creates more work, thus exacerbating the smarter/harder tradeoff and the work is not going to wait Eventually, forces people to take short cuts, which when discovered provide more evidence confirming that the people are the problem.

Consequences of Self Confirming Attribution Errors

Measurement systems become increasingly shortsighted and restrictive
...supervisors were evaluated on labor performance on a daily basis. Penalties for missing targets become more severe ...supervisors who missed their targets knew they were going to get beat up by their managers.

the only thing they shoot you for is missing product launch Line workers invent new methods to insure they are never penalized. It didnt take long for them to develop a buffer in front of their line so that if the schedule called for 700 and their line was fully utilized at 800, they could still run 800 units every day, and still make their labor performance. The organization becomes increasingly focused on compliance

FAE
Performance Degrades

overload

Fundamental Attribution Error

People working for me are lazy

Need more accountability, controls

Why they dont think much of you either

When firms get caught in the capability trap and the selfconfirming attribution error, what do senior leaders do?
They spend a lot of time on fighting fires, providing oversight, and fixing specific problems And very little time on developing strategy, setting priorities, and thinking about the system

Paradoxically, this approach to leadership increases stuckness

Without clear priorities you cant kill project 26 (since its a good project) Senior leadership oversight creates more work for those closer to the front line and often feels ceremonial and disconnected from the real work Leads to initiatives that are inconsistent with the underlying time constants of the operating sites

Why cannot the project be killed

Its a good project!
Good managers can meet stretch goals (and Im a good manager) Making difficult decisions would imply that we:
Had a strategy that we could use Could talk to each other in productive ways Its very hard to do either when youre overloaded

Blame leaders, others

Declining performance

overload

The what on earth do they think they are doing loop

We dont have time to reflect

We cannot make decisions

Project Management and FAE

My people are lazy Productivity falls

overload

Early stage work neglected

Declining performance

What are they thinking?

No time for strategy

Fix things now or work on longer term capability

Capability
Invest in capability Capability erodes Time

Actual Performance

Time spent on implementation/impr ovement Desired Performance

Work harder or work smarter

Capability
Invest in capability Capability erodes Time

Actual Performance

Time spent on implementation/impr ovement Desired Performance

Pick one
Working harder yields better before things get worse

Working smarter yields worse before things get better

How to manage therefore?

Manage capacity Complement bottom up with top down Manage worsebeforebetter Focus on eliminating defects with the best cost/benefit ratio Change your habits around problems Respond to a screwup as though it were a capability problem Have a clear strategy and live by it

Manage Capacity
It is hard to avoid getting stuck if you take on more work than you have the capacity to do Capability development and defect elimination inevitably suffer (just do it doesnt) Most organizations try to do this (if at all) with a bottom up approach Start with all the work you want to do Estimate resources requirements Add it up and cut everything that falls below the water line While necessary, this rarely works on its own Individual task estimates are notoriously unreliable We have a strong psychological tendency to assume that everything will proceed according to the best case It is very easy to say we can make space for one more

Top down approach

Keep good records of what you accomplished last year (or quarter)
Compare what you did last time with what you are planning on doing this time If you are planning on doing more this year than last you better have a good story for why this is feasible Its not unusual for these to be off by more than a factor of two HarleyDavidson made huge progress just by recognizing that they could not do more than one big project a year

Manage worse before better

Pick the capability investments and defect elimination projects that have the biggest bang for the buck Start small and do lots of little projects Make sure you reinvest some portion of each success in another project

Change habits around problems

We all make the Fundamental Attribution Error and suffer from its consequences. The trick is to change your habits around how you respond to problems. From a manager of a successful initiative:
There are two theories. One says theres a problem, lets fix it. The other says we have a problem, someone is screwing up, lets go beat them up. To make improvement we could no longer embrace the second theory, we had to use the first.

Clear strategy and living with values

For the people that you lead:
Spend time on clearly articulating your priorities in concrete ways; operational examples are key! Make it very clear what is supposed to fall off the table when people are in a resource crunch; they are just as prone to overcommitting as you are Praise them like crazy when they make the difficult decisions

For the people that lead you:

Ask for clear priorities and dont continue the conversation without them Dont sign up for more than you can do (even if you are pushed) Escalate when you are being pushed off your agreed upon values and strategies with concrete examples and data (pay now or pay later)

Develop ability to have real conversations

This would only work if we told each the truth, wouldnt it? this requires having conflict. Intriguing research shows that top management teams with moderate conflict have high performance than those with no conflict.

Rapid Decision Making in fast moving, and ambiguous environments is critical and helps to mitigate overload Best Practices for Speeding Decision Making (from a multicase study of computer firms):
Counterintuitive: faster decision making involves considering more simultaneous alternatives than slower firms
Considering more alternatives prevents costly revisits, is more easy to evaluate than decisions in isolation, and reduces escalation of commitment to poor options e.g., hard to buy a car without looking at multiple cars

Fast Decision Making in Tech Environment

Use of experienced counselors speeds decision making:

Hasten development of alternatives, and mitigates lack of confidence

Use of active conflict resolution speeds decision making

Decision Making Velocity and Performance

Faster decision making has been repeatedly linked to higher performance in these settings

Slower decision making produces worse, not better outcomes as the environment changes and firms fail to make some critical decisions

Risks in Project Management

It is risky that is why benefits are so high It can yield big benefits thats why it also so risky Project Proposal will include: Why is it required?
Financial benefits (time, money), qualitative benefits (reduce stress, increases csat)

What does it take to happen?

Time, money, people, processes, technologies, partnerships

Scope of project and what is not in scope What constitutes a change? How will change request be managed?

How to recognize if a Project is HIGH RISK

Project size
Large budget (relative to historical spend) Many functions, teams, departments involved Long duration (more than 6 months)

Experience with technology

Poor knowledge of h/w, s/w and other technologies used Introduction of new technology

Changing requirements
If the goal post keeps changing or any reason, project is at higher risk of failure

Framework for Visualizing Project Risk

Very high risk

Hi Requirement Volatility Low tech Spreadsheet: sales forecast, budgeting, production planning ERP for Demand Planning, Production Planning

Low Requirement Volatility Roll out BlackBerry

Project Risk

High risk Moderate risk

Hi tech

2 # of risk factors

Roll out ACD, VoIP, IVR, CTI apps in call center

Use this to communicate to all levels before, during and after project

Practical ways to understand Project Risks

Review Questionnaire on Page 458 Stop being a hero, lone ranger Be honest and transparent with leadership and all levels

Expectation setting during Projects

Cut over is never smooth Business users will doubt IT team at cutover since everything will be difficult at that time Organization culture becomes clearly visible at cutover time: is it supportive or do people look out for themselves Projects can collapse during cutover Need to constantly educate about short term dip before performance picks up Need to be all hands on deck at cut over to quickly identify Very Urgent, Very Hi Priority problems and to solve them Project and Account Managers have to stop selling the wonderful vision of how things will look after cutover

Risk-Return of Portfolio of Projects

Always take a Portfolio view and not one off
Project Benefits
New Core Value V.High New Benefits Improved Benefits Variation

Project Risk

High

New Projects

Ongoing Projects

Medium

Low

Are projects aligned with strategy?

Tools to manage projects

External integration tools Internal integration tools Formal Planning tools Formal results control tools

External Integration Techniques/Tools

Select a Project Manager Set up Steering committee with scheduled meetings Setup change control process Regular distribution of project team info to team members Selection of right team members Setup approval process for system specifications Prototype with end users Create periodic progress reports Get users involved in key decisions/actions

Internal Integration Techniques/Tools

Select experienced IT professional to lead tech team Periodic team meetings (Scrums) Periodic distribution to team of info on design/testing Tech status reviews HR interventions to keep attrition low Select team members who have worked together Users to participate in goal setting, deadline setting Get technical assistance from outside

Formal planning tools

Project management software PERT, CPM Estimation tools Systems Specification Process (PRD, SRS, FRS, HLD, LLD) Project approval process Post project audit process

Formal Results Control tool

Current status vs. plan reports Change control discipline and systems Milestone reviews Root cause analysis for deviations from plan

TOOLS FOR PROJECT TYPES

Low requirement volatility: Low Tech

Project Characteristics: Simple
IT team does not need to engage with business users deeply Little to no change management requirement Complex planning not required Deep dive analysis by IT business analysts into each function not required Significant time not required from end users to design End user approval not required for design docs

Type of skills required: Average

Average skill people are good enough Project Manager can be of average skill Tech lead can be of average skill

Outcome: Predictable
Simple planning tools like GANTT chart, PERT, CPM work fine and give predictable results Usually stick to budgets These are low stress projects

Low requirement volatility: High Tech

Project Characteristics: Tending to complexity
IT team does not need to engage with business users deeply Little to no change management requirement Complex planning not required Needs good understanding and agreement on business process changes Need close collaboration, detailed documentation, regular meetings to cope with tech shortcomings Deep dive analysis by IT business analysts into each function not required End user approval required for design docs

Type of skills required: High

Good skill people are good enough Project Manager needs to have experience in high tech projects Tech lead to be highly skilled in area

Outcome: Unpredictable
Planning tools are less important than ability to handle tech complexity Unpredictable effect on budgets These can become high stress projects

High requirement volatility: Low Tech

Project Characteristics: Complex
IT team needs to engage with business users deeply at multiple times Significant change management requirement Complex planning required Needs good understanding and agreement on business process changes Need close collaboration, detailed documentation, regular meetings to cope with tech shortcomings Deep dive analysis by IT business analysts into each function required End user approval required for design docs, prototypes, test cases

Type of skills required: Average Tech; High Collaboration

People with average tech skills Business analysts with excellent skills required Project Manager needs to have significant experience Tech lead to be average skilled

Outcome: Unpredictable
Planning tools are less important than ability to handle tech complexity Unpredictable effect on budgets These can become high stress projects

High Requirement Volatility: Low Tech

Project leader has to be very high in hierarchy Steering committee to meet and evaluate periodically Break project into manageable milestones Formal user review and approval at each milestone Communicate formally; distribute minutes after each meeting Adhere to all milestone timelines Keep people attrition low, because project knowledge goes away End users have to drive these projects and never technologists. So role of BUSINESS ANALYSTS is vital

High Requirement volatility: Hi Tech

Project Characteristics: Complex
IT team needs to engage with business users deeply Good change management process requirement Complex planning and control methods required Needs good understanding and agreement on business process changes Need close collaboration, detailed documentation, regular meetings to cope with tech shortcomings Deep dive analysis by IT business analysts into each function required End user approval required at all levels

Type of skills required: High

Good domain, good technical skills Project Manager needs to have deep experience in such projects Tech lead to be highly skilled in area

Outcome: Unpredictable
Planning tools are less important than ability to handle tech & requirements complexity Unpredictable effect on budgets These can become high stress projects Excellent leadership required to guide through difficult times

Challenges in Project Management

Volatile requirements, rapid technology changes Vendors require significant upfront payments

Poor work ethics and focus on short term:

People look for salaries and not learning so hop jobs Leaders want quick results: ruthless, greedy, low integrity

Outcomes are uncertain

Time taken for completion is uncertain

Old method to address challenges in PM

SDLC: System development life cycle
Analysis & Design
Analysis: IT + Business users/consultants Design: IT Establish: What has to be done? Why (Cost-Benefits)

Build
IT builds Alpha, Beta tests Intense collaborations between dev, UI design, Testing, Documentation teams co-located or dispersed or outsourced Close controls to stick to time & budget

Implementation
IT and End Business user work in tandem Management of Testing, training, disruption of normal working

Operate & Maintain

Migrations, bug fixes, ongoing customer support, indexing Keep the fires burning

New method to address challenges in PM

Adaptive Methods
Iterate: start with rough outline of requirements and learn as you progress. Design, build and implement in small bites and test before moving to next bite Fast cycles, frequent outputs. Discourage long lead times and variable delivery times. Give small, logically complete features to end users so they can tell you if it is useful Requires highly skilled people to learn and do Avoid ROI computations. Instead go with market needs and size of market

SDLC
Extensive upfront planning to get everything right ROI calculations done way in advance Little scope for accommodating new use cases Tend to over engineer Tendency to ignore complexity, looming disasters Ego of people involved is given more importance

Adaptive
Little to no upfront planning. Learn as you go. Based more on market size for product Very flexible. Easily accommodate Deliver what will get consumed Can easily test and fix without burning time or budget User needs are given more importance

Blending agility with rigor/consistency

Simple tools to ensure agile model is also a consistent and not a totally fluid model:
Flow: Understand the context: Create flow charts so people know what happens and in what order and when. Get the picture! Completeness: Details: what needs to be done, by whom, when, where, why and how. Build checklists! Visibility: Create Trust: publish progress reports on charts that everyone who needs to can access. Physical or online.

Weill and Aral IT Asset Portfolio Diagram

DISCUSSION

Viewing IT as a Portfolio of Assets

Spend:
Expenses (Ex. cartridges, paper, website design) Assets: PCs, Servers, Printers, Scanners

Investment:
Risk/Return trade off

Strategy aligned to IT investment:

Short term / long term risk return payoff

4 Management Objectives forMIT Sloan CISR investing in IT

1. Transactional
Cut costs, increase throughput for the same cost Examples: Core Banking, Core Insurance, Stock Trading Software, Railways reservation

2. Informational
Provide information to Manage, Control, Account, Report, Communicate, Collaborate or Analyse Example: CRM, Sales Management, BI

The Strategic Approach

3. Strategic

MIT Sloan CISR

Gain competitive edge Examples: ATMs, Hand held Trade Promotion Management devices, GIS based vendor mapping

4. Infrastructure
Essential foundation like electricity Laptops, printers, servers, networks, databases

How is money typically spentMIT Sloan CISR on IT?

54%: 13%: 20%: 13%: Infrastructure Transactional software Information systems Strategic Systems

Infrastructure: Features/Benefits
What it can do Business integration Business flexibility Reduced marginal cost of BUs IT Reduced IT costs Standardization

MIT Sloan CISR

Returns Higher market valuation Faster speed to market Smaller short run margins Lower Return on Assets

Transactional: Features/Benefits
What it can do Cut costs Increase throughput

MIT Sloan CISR

Returns Higher sales per assets Lower cost of goods sold 25-40% return

Informational: Features/Benefits
What it can do Increased control Better information Better integration Improved quality Returns Superior quality Premium pricing Larger margins Higher ROA

MIT Sloan CISR

Strategic: Features/Benefits
What it can do Increased sales Competitive advantage Competitive necessity Market positioning

MIT Sloan CISR

Returns 50% fail Few spectacular successes 2-3 year lead Premium pricing More sales from modified and enhanced products