Managing Challenging Projects Presented to the class of: Dr. Jane Mackay M.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) 2 November 2008 Takeaways Pay 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 3 November 2008 Takeaways Project 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 key functional elements Technical: Defines system infrastructure including hardware, OS and support applications Creative / UI: Defines usability and creative design guidelines including colors, fonts and response times Detail Design: Documents used as necessary to detail design for complex build items 4 November 2008 Takeaways Design 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 5 November 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 6 November 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 7 November 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 8 November 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 9 November 2008 Takeaways No 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 10 November 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 11 November 2008 Takeaways JAD 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 12 November 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 13 November 2008 Contact Details Jeff Hattendorf