240 likes | 408 Views
Project Management. Project Management Processes with Case Examples. Gregory Neal Ph.D. CIS 480 . Reasons for Project Success. Clear system requirement definitions Substantial user involvement Support from upper management Complete and detailed project plans
E N D
Project Management Project Management Processes with Case Examples Gregory Neal Ph.D. CIS 480
Reasons for Project Success • Clear system requirement definitions • Substantial user involvement • Support from upper management • Complete and detailed project plans • Realistic work schedules and milestones • Adequate project resources • Proper execution of control processes
IS Project PhasesSurrounded by PM Processes Project management processes surround the execution of system development processes The project tasks can be traditional or Object-Oriented and the methodology can be Waterfall or Iterative, however the surrounding PM processes still need to be there!
Scope management Time and schedule management Cost management Quality management Human resource management Communications management Procurement management Risk management Project Management Body of Knowledge (PMBOK) Spans all Process Groups Project Management Institute, “A Guide to the Project Management Body Of Knowledge,” Project Management Institute, 2000.
Management Process Time Allocation Run a 6 hour day for worker Productivity against project tasks
Project Plan and WBS Milestones and Major deliverables
Project Schedule Gantt Chart CPM ACTIVITY ANALYSIS PERT
ABC Project Description • ABC Project Characteristics • Major Retirement System Replacement • Use of a customized COTS system as replacement • Custom development of security, reporting, and Internet system functionality • Custom integration with existing systems • Need to convert legacy data from replaced systems • Full lifecycle initiation, analysis, design, testing, training, and implementation • Environment • Multiple language (Forte, Java, Fortran, COBOL, Natural, PeopleSoft, PowerBuilder, Visual Basic) and database (AdaBase, Oracle, VSAM) technologies • Multiple platforms (MVS, Unix, Windows XP) • Large geographic distribution with 8 regional offices • Size • Budget over 20 million dollars • Total implementation timeframe 2.5 years • 1000 internal users, 1.5 million plus external users
ABC Project: Plan & Schedule Key Issues • Got behind on plan development and status reporting so: • Contractors brought in from outside of project • Unfamiliar with project documents • Didn’t know project management tool and discovered defects during use • Outside contractors resulted in conflict with internal team members • Client PM overreacted to state of plan development causing escalation of issues • Project management team failed by: • Not recognizing difficulty of task causing all estimates to be overly optimistic • Endangering client relationship by not meeting deliverables in a timely manner
ABC Project: Plan & Schedule Key Issues • Executive Management failed by: • Ignoring project team recommendations on schedule extension • Failed to understand the complexity of the on-site environment and client approval processes • Client Project Management Office (PMO) raised issues because of: • Tool guru's were not helpful and tried to protect their “expert” image to promote additional work for themselves • Guru’s made corrections and deleted entire project management plan repository • Client PMO requested violation of scheduling “Best Practices” • Task were created at too small a granularity (i.e. per meeting basis) • All client resources were overloaded across projects to 150% - 200% • Project plan standards like naming conventions, resource v.s. task based activities were not in place so the team received bad guidance
Issues Management Internal Factors External Factors Issue Resolved Review and Status Issues at Weekly Meeting Resolution Issue Resolution Generate Reports Issue Tracking Risk Status Changed To Risk Escalate to the Program Review Board Issues • Tracking Number • Impacted Activity • Impact to Project • Identifier • Date • Target Resolution • Criticality • Status • Name • Description • Possible Solution • Resolution • Resolution Date Issue Identified Owner Assesses and Resolves Mitigation/Contingency Options Issue Documentation Document Issue in (Access Database) Issue Analysis Analyst Assigned to Investigate and Present Options Escalate to Change Control Board
Status Logged Project Staff will Schedule and Implement the Requested Change Change Implemented and Tested Request is Logged in the Change Control Register Change Requested PM Adjusts PMP, Budget, and Schedule to Reflect Impact Triage Change Through PM CCB Considers Findings Approved Rejected Change Control Board Reviews Request Impact Analysis of Making the Change or Not Analysis Change Control Process
ABC Project: Scope & Change ControlChallenges • RFP was incomplete as to the extent and complexity of system interfaces • Existing systems were not compatible with financial data in new system • Complexity of organization and approval much greater than estimated • Information systems staff limitations greatly restricted workflow • Contract was a fixed price bid with penalties for late deliverables
ABC Project: Scope & Change ControlKey Issues • Scope of system interfaces grew by 23 additional system interactions • Each interface needed to be addressed separately for client • Client interpreted broad requirements as being all inclusive of additional interfaces • New interfaces were estimated to cost $2.5 million and take 8 months to complete • Client Project manager was involved in creating RFP so the additions were politically unacceptable • Existing system would not support financial data integrity • Lengthy analysis would need to carried out to determine how to change existing system • Rewrite of current systems would be necessary to correctly handle record deletes • Current business processes would need to reengineered to to support changes in existing system • Existing system built on obsolete technology platforms
ABC Project: Scope & Change ControlKey Issues • Organization complexity greatly under estimated • Analysis sessions involved as many as 50 to 60 people • Couldn’t get user agreement and achieve sign-off on analysis scenarios or business rules • Approval process ran long taking 6 weeks instead of contract 10 days • Lack of clarity of deliverables forced “analysis paralysis” • IT resources over committed • Technical people not adequately represented at meetings causing issues to reopened after analysis • Issues could not be brought to timely resolution since technical people unavailable so design task delayed
XYZ Project Description 1. Zurich, Switzerland • XYZ Project Characteristics • Build Medical System • Develop canned medical system including • Billing • Patient records • Claims • Staffing • Adapt model already used in Europe • Target market State medical insurers • Environment • Language C++ and relational database • Platform (Unix server, Windows client) • Development in India, US (Phoenix, Washington DC, with engineering staff in Zurich • Size • Budget over 40 million dollars • Total implementation timeframe 2 years • > 100 internal users, > 500 external subscribers 2. Phoenix, AZ US Medical System 3. Washington, DC 3. India
XYZ Project CommunicationsChallenges • Get three companies with different culture backgrounds on three continents to work together • Make technology work effectively for development and testing across three continents • Provide timely direction and control communications • Management subcontract communications effectively
XYZ Project CommunicationsKey Issues • Culture and time differences • Swiss company, German CEO and engineering staff, India off-shore development, US management of development caused many conflicts • Time differences limited the available teleconferences • Multiple companies with conflicting statements of work • Swiss owned parent to build and sell end product • US consulting firm to provide US management • India developers in both DC and India • Who does analysis for US? Who does screen design for German code generators? How is the QA handled?
XYZ Project CommunicationsKey Issues • Provide delivery of components, test and new product releases • Problem was keeping everything in synchronization • Delivery of test result was very problematic for engineers to review • Managers in Zurich didn’t understand status reports from US • Management staff on-site in DC were not effective • Manager misrepresented credentials • Manager lacked understanding of technology
Conclusions • Project management is DYNAMIC! • If something can go WRONG or CHANGE it will! • Project management is like JUGGLING MANY BALLS in the air at once. • Project managers must have a large BAG OF TRICKS including understanding of the project, methodologies, techniques, costs, schedule, processes, people, tools, quality, and communication. • Project management is the ART of dynamically planning, executing, monitoring, and controlling all aspects of the project to deliver within cost and schedule!!!!!