Embed Size (px)
Citation preview
eProject Management: Methodology or Madness
Philip R. Diab, MIM, PMP
Senior Project Manager
IBM
Minnesota Chapter – July 2002
Introduction
• Old business strategy versus the e-Business age.
• Speed of delivery at the heart of the discussion.
• Can proper Project Management standards be followed in an era where project delivery timeframes could last as little as two weeks?
Scope of Discussion
• Have traditional business strategy models become obsolete in the new information age?
• Does the internet age offer a new business model or is it a technology enabler?
• The dust has settled and the dot-coms are now dot-gones.
• Adhering to generally accepted Project Management principles can result in success.
• The best evidence of this is successfully implemented projects.
Project Case Study
IBM Customer Engagement
The Customer
• For confidentiality purposes, I will refer to the case study as The Customer.
• The customer is an internet startup spin off of a fortune 500 company.
• Insurance sector of the financial services industry.
• Focus on business process integration.
• Maturity level in Project Management is low.
Project Synopsis
• The customer needed to develop a private e-marketplace.
• Project involved IBM providing software, hardware, services, internet hosting.
• Total project cost in excess of $2.5 Million.
• Critical success factors match the characteristics of an E-business Project.
• The team utilized the PMBOK Guide framework, IBM Methodology and tools during planning and implementation.
Required Critical Success Factors
• Rapid delivery of the solution.
• Quick requirements prioritization process.
• Successful management of multiple sub-projects and complex project team organizations.
• Fast completion of project deliverables.
• Strong use of a methodology to plan, track, and correct project performance.
Focus on the PM Knowledge Areas
Based on PMI’s PMBOK Guide
Project Integration Management
• Context:– Solution to allow for evaluation of insurance quotes and financing including
quotes and new business processing– Solution users included insurance agents, brokers, insurance carriers, and end
customers.
• Challenges:– Requirements complexity.– Future needs.
• Process:– Proposal, Concept, Solution Design, Initiation, Planning, Execution, Controlling,
and Closing.
Project Integration Management -- Continued
• Best Practices:– Combined PMBOK Guide Framework with IBM internal methodology.– Capturing lessons learned as part of day to day management– Closeout meeting to gain official signoff – simple but needed.
• Lessons Learned:– Involve PM during sales process.– Transition meetings between sales and delivery.
Project Scope Management
• Context:– Design, develop, test, and assist in the transition into production, a solution that
consisted of a GUI system, process flow, business rules engine, and messaging.
– Utilizing internet technologies was a key.
• Challenges:– Contract signing dragged on.– Scope not clearly defined at SOW signing.
• Process:– Defined requirements process as part of contract.– Defined configuration management process from the start.– An iterative approach to project reviews.
Project Scope Management -- Continued
• Best Practices:– Using a systematic approach to define and prioritize requirements based on
IBM’s requirements and specifications guidelines and processes.
• Lessons Learned:– Avoid the de-scope and extend principle.– Divide deliverables into “work products” and deliverables.– Identify the difference in the SOW.
Project Time Management
• Context:– Speed, speed, and speed.– Made commitments prior to defining requirements.
• Challenges:– Tying business requirements to customer commitments meant very little
flexibility.
• Process:– Defined WBS.– Developed activities and business events.– Created the schedule.
Project Time Management -- Continued
• Best Practices:– The ability to develop the WBS allowed the whole team input and a true
understanding of the scope.– Tracking hours to specific activities within the project enabled a better
assessment of performance and progress.– Building one project schedule that encompassed all sub-projects gave a global
view of the project.
• Lessons Learned:– Did not rely on IBM templates in developing schedules thus “recreated the
wheel.”– Not every individual had access to scheduling software. We did not publish the
updated schedule in an electronically readable format.
Project Cost Management
• Context:– Our team assisted the customer in developing the cost baseline because we
provided a total solution.– The sales and delivery team worked together in estimating costs.
• Challenges:– Multiple internal and external organizations had to contribute to estimating
effort.– Tracking was a challenge because of multiple organizations.
• Process:– Utilized IBM tools and standards was an important factor in tracking costs and
communicating to the customer.– Weekly progress reports were used both individually and by team.
Project Cost Management -- Continued
• Best Practices:– Requesting that each individual provide their weekly status report to include
hours worked and travel expenses incurred was a good validation strategy for invoicing.
– Tracking costs based on project activities.
• Lessons Learned:– Resource grade of supplier employees was not taken into consideration
resulting in rework of estimates.– Resource skill level had to increase to meet complex requirements resulting in
rework of estimates.
Project Quality Management
• Context:– Had to work hard at designing quality into process.– Rapid development approach made it even harder.
• Challenges:– Parallel and competing activities.– Pre-defined milestones and cost baselines.
• Process:– Source Code control was imperative in the management of solution quality.– Quality reviews were held frequently.– IBM’s standards established PM quality requirements.
Project Quality Management -- Continued
• Best Practices:– The use of existing IBM processes and infrastructure as opposed to fighting
organizational standards enhanced team performance.– The ability to distinguish between quality standards for managing the project
versus quality standards in producing the solution helped the team understand the necessity for both.
• Lessons Learned:– If the PM is unable to make adjustments to either the scope, cost, or time, due
to a change in the project or if a risk is realized, the only option is to let quality slip. That was a tough lesson to initially discover, but a very valuable one that we learned early on.
Project HR Management
• Context:– Multiple internal organizations.– Multiple external delivery companies.
• Challenges:– Third party managed by our team.– Needed to pay close attention to regulations.– On-boarding due to different phases.
• Process:– Established orientation plan and manual.– Defined roles and responsibilities for each individual and tied to deliverables.– Utilized Lotus Notes Teamroom to communicate and document.
Project HR Management -- Continued
• Best Practices:– Developing a timeline of resource needs was critical to ensuring “just-in-time”
availability of resources.– Defining a process that allowed the PM team to dismiss resources that lack the
necessary skills to accomplish their tasks.
• Lessons Learned:– IBM’s complex organizational structure and process made the challenges
faced by the team even greater. Tapping into the knowledge and network of seasoned team members helped mitigate some of those risks.
– The team initially did not have a strong mix of senior and junior resources.– There was a need to establish a process for awarding performance during the
project as opposed to at the end.
Project Communications Management• Context:
– A simple requirement to distribute information quickly, consistently, clearly, and accurately.
– Customized templates were used to communicate issues, status reports, change requests, and risks.
• Challenges:– Team size and locations.– Need to constantly remind to follow agreed upon process.
• Process:– PM as a primary point of contact.– PM team meetings were used to review progress and status.– Used Quickplace to store information and communicate with the customer.
Project Communications Management -- Continued• Best Practices:
– Utilizing an internal teamroom and an external Quickplace collaboration site served as an important method for communicating and documenting. This also separated the confidential internal items from the external items.
• Lessons Learned:– Developing a team lexicon of common PM and business process terminology
would have increased chances of meeting time, cost, and scope needs.
Project Risk Management
• Context:– New and unproven technology.– No chance to develop avoidance strategies, only mitigation.– De-scoping is a real life option as a mitigation strategy.
• Challenges:– The customer did not display a clear understanding of risk mitigation strategy.
Needed to educate on process.
• Process:– Internal risk assessments were used to determine risk events and quantify
them.– Mitigation strategies were developed.– External risk assessments were also held. Why separate?
Project Risk Management -- Continued
• Best Practices:– Conducting risk assessments frequently enables the team to identify potential
risks early.– Maintain a simple process: identify, quantify, mitigate, and communicate.
• Lessons Learned:– Conducting additional risk assessments with the customer to better explain
responsibly related to mitigation. If/then scenarios needed.
Project Procurement Management
• Context:– IBM purchased and resold third party software and services.– Complex agreements were required to navigate multiple organizations.
• Challenges:– Third party resource skills were not at the level needed to get the job done.– A detailed analysis of third party software revealed a lack of alignment between
solution offering and customer needs.
• Process:– Many of the processes followed in this area were IBM pre-defined processes
utilizing proprietary systems. Up to the minute reporting through these systems were available to track costs and revenues.
Project Procurement Management -- Continued
• Best Practices:– Designing a contracting process that protected the organization and the project
team. The team utilized document templates such as the SOW to communicate with suppliers their roles and responsibilities.
• Lessons Learned:– To ensure that services suppliers provide resources with the necessary level of
skills to get the job done in accordance with the contract.
Project Results• Expectations management ensured satisfaction resulting in follow-on
business.
• Team responsibilities were outlined early. Individuals maintained a good work ethic and were rewarded adequately. Several team members received IBM awards.
• Project business objectives were met, however, minor scope modifications were required based on needs.
• Strong communications on progress helped ensure everyone was aware of status. The team met its agreed upon timeframe.
• Project revenue and profit targets were met, with a variance of no more than 10% based on the scope and approved change requests.
Success in this Environment• What does it take to achieve success in this environment?
– Quick decision-making. Empowering the Project Manager and delegating to the team.
– Clear establishment of business objectives and understanding of business drivers.
– A plan that breaks deliverables into achievable small milestones.– Defined, prioritizes requirements. Eliminate gold plating.– Utilized proven Project Management framework, don’t reinvent the wheel.
Conclusion
• Going back to the original question:– Have traditional business strategy models become obsolete in the new
information age?
• The difference is in the focus on one item:– Speed
• Experience, training, and timely delivery are essential.
