Managing Challenging Projects

Presented to the class of:Dr. Jane MackayM.J. Neely School of Business

General Project Documentation Business Documents

Proposal Internal / Vendor: Define the

business issues and challenges to be overcome, solution(s), costs and cost drivers

Contracts Internal distribution

Work order / statement of work Summary of general terms and conditions including Non-Disclosure

Agreements Files

Executed copies of originals Electronic copies (easy access)

2November 2008

TakeawaysPay special attention to the documents that are prepared and presented during the sales effort … expectations are being set.

It is much easier to raise expectation than to lower them.

Share those expectations and commitments with the entire project team.

General Project Documentation Project Documents

Project Plan(s) Project Timeline: Identify key

timeline components and dependencies

Communication Plan: Defines communication guidelines including frequency, participants and progress reporting

Escalation Plan: Defines procedure(s) for escalating issues that the joint (client – vendor) project team are unable to resolve

Business Requirements Document Business Requirements: Document detailed business requirements

such as data required to manage a process Process Flow Diagrams: Document ‘As Is’ and ‘To Be’ processes

3November 2008

TakeawaysProject plans are important tools for setting and managing expectations.

Be conservative in your planning.

General Project Documentation Project Documents (cont.)

Specifications General Design Document:

Provides an overview of the solution to be implemented identifying keyfunctional elements

Technical: Defines system infrastructure including hardware, OS and support applications

Creative / UI: Defines usability and creative design guidelinesincluding colors, fonts and response times

Detail Design: Documents used as necessary to detail design for complex build items

4November 2008

TakeawaysDesign is as much art as science and can go on and on if it is not managed.

Design should continue until the value of additional design is outweighed by the cost of delays in getting started.

Case Study: Overview Sales Cycle

Duration: 4+ months

Discovery & Initial Design Duration: Approximately 4 months

Activities Business user interviews SME interviews Existing application review

5November 2008

Case Study: Overview Discovery & Initial Design (cont.)

Results Business Requirements Document (150+ pages) Process Flow Diagrams Design Documents (200+ pages) – high level application design

including modules, functions and data

6November 2008

Case Study: Overview Detailed Design & Development

Duration: Approximately 18 months Activities

Detailed component design Application modules coded, tested and deployed

Results Updated design documents Completion of user interface & 90+% of application functions

Data Conversion Excluded from the scope of the development project Necessary on a limited scale for testing Required for full system deployment – including data validation

7November 2008

Case Study: Key Issues Communication

Constant and consistent Weekly status meetings Flash updates as warranted

No surprises Share good news and bad when it

becomes available Clients may chafe at first but will

respect it as the project goes on

Single Subject Matter Expert Avoid a single SME

Creates difficulties during user acceptance testing Limits design to knowledge from a single person / business user

8November 2008

Case Study: Key Issues

Single Subject Matter Expert (cont.) Avoid a single SME

Creates difficulties during user acceptance testing

Limits design to knowledge from a single person / business user

Costs much more in the long run No buy-in from other members of

the client organization “Silo” view of system likely to lead

to re-design / re-build efforts

9November 2008

TakeawaysNo surprises – good or bad – to maintain credibility.

Maintain accountability for all parties on project deliverables and manage timeline expectations when they are late.

Involve a manageable number of subject matter experts / business users to develop buy-in during the project.

Challenging Project: Key Issues Data Conversion

Significant issue whenever a prior system exists

Can last as long or longer than the original project

Issues can include: Missing data that is required in new system but not old GIGO – bad data in the old system that will not convert in an

automated fashion Mismatched data – data integrity and/or data entry rules not

enforced in the old system, e.g. Financial application allowing negative invoices instead of requiring credit memos

10November 2008

Challenging Project: Key Issues Ongoing Design Changes

Lock the design early in the project – get client signature on final documents

Manage changes through change orders – get client signature

Ripple effect can be hard to predict

11November 2008

TakeawaysJAD documents are not design documents – communicate this to the client.

Lock design, get client approval (written) and develop to the design.

Data conversion can be similar in ‘size’ as the original project.

*** Clients (and many consultants) generally underestimate data conversion and validation efforts.

Case Study: Conclusion Application was stopped prior to completion and the

application shelved

Could have been saved? Technology – yes

Functioning application lacking only data conversion and deferred functions

Pending activities Final performance testing and code clean up last step necessary prior

to deployment Data conversion scripts working Staged deployment and parallel processing

12November 2008

Case Study: Conclusion Could have been saved (cont.)

Emotionally – no Communication break down among the project team members

created an emotionally charged environment Application lacked support in the business user community – single

SME limited their input during the project until testing began

Open Q&A

13November 2008

Contact DetailsJeff Hattendorfhattendorf@gmail.com