Download
1 / 35
350 likes | 361 Views
MIS 495 Scope of Project Management. Dr. Honghui Deng. Associate Professor MIS Department UNLV. DEFINING IT PROJECT SCOPE. Project scope. Two important interrelated questions: What is to be developed? How it should be developed? This is true for
E N D
MIS 495 Scope of Project Management Dr. Honghui Deng Associate Professor MIS Department UNLV
Project scope • Two important interrelated questions: • What is to be developed? • How it should be developed? • This is true for • Developers (project manager and team members) and • Recipients (users and sponsors) • Both must be clear on project ‘intent’.
Project specifications • Project success is closely tied with user needs specification. • It is important for the developers to understand exactly what the project is expected to accomplish. • Effective allocation of resources is dependent on it. • It saves time by eliminating features that have little value to the customer.
Project scope • Project scope is the guide for developing project plan. • Project plan is the guide for project execution. • Thus, project success is directly linked with the project scope. • Project scope is developed by the project manager in close collaboration with the customer.
Project scope content • It clearly describes deliverables that are: • Realistic and • Doable • It is a source for measuring progress and controlling quality. • It must be clear on: • Overall objectives • Specific deliverables • Milestones • Needed resources
Overall objectives • Example, “to develop and implement a web based inventory system that integrates all suppliers within 18 months at an approximate cost of $100,000.” • This statement suggests what is expected, when it is expected, and at what cost.
Deliverables • Must be defined with specific time and cost projected. • Example, “a prototype of a system within two months at the cost of $25,000.” • Deliverables are used as a base to assign responsibilities and evaluate performance. • Collectively, deliverables accomplish the overall objectives of the project.
Milestones • A milestone reflects an event - a point in the life of the project when a significant accomplishment has been made. • Example, prototype test is complete • Milestones are based on deliverables and used to monitor progress. Once milestones fall behind schedule it is an indication that the entire project may be delayed. • They must be easily recognized by all team members and sponsors.
Resources • Divided into three main components: • human resources (talent and skills required in the team). • facilities and equipment (communication channels, testing tools). • organizational (support, collaboration with inside and outside entities). • Exclusion or exemption clauses can be included when unusual situations are expected. • Once agreed, get developers and sponsors to sign the project scope statement.
Project charter • Used to get authorization for a project and includes: • project title • project sponsors • project manager’s name • start date • project objectives • project cost and resources • completion or due date • Does not replace ‘scope’ and is not always used.
Project charter example • Project title: OS migration from NT to XP • Project sponsors: IT Support Services • Project manager: Misty Blue • Start date: November 1, 2004 • Project objectives: Upgrade operating systems to XP for all employees within 6 weeks. See attached page for the list of eligible employees. • Project cost: Budgeted $50,000 for labor costs and $20,000 for software. • Completion date: December 15, 2004 • Comments: We expect Dew Berry and Jap Napa from Instructional Development Office to work on this project. See attached for the list of team members.
Work breakdown structure • Breaks down the entire project into manageable parts. • Each part becomes a ‘work unit’ with its cost, responsibility, due dates, and so on assigned to it. • It is similar to an organizational chart where a quick glance will tell us the number of divisions, the hierarchy, people responsible for each division, size of each division, and so on.
WBS Video 02 Work Breakdown Structure
WBS – Webpage project • Consider, for example, a simple information system project that has the objective of developing a webpage for a small business. You may break down this project to three phases of: • Design • Development • Implementation • These activities are further defined as:
WBS – Webpage project • Design phase involves • Needs analysis determined through interviews with the business owner and employees. • Review and selection of software and languages • Development phase involves • Purchase software • Write programs and test • Review the product with the user • Make revisions based on feedback from the user • Implementation phase involves • Select server site • Obtain permission • Install and test
WBS – Coding scheme 1.0 Design 1.1 Needs analysis 1.1.1 Define owner needs 1.1.2 Define user needs 1.2 Software selection 1.2.1 Define system needs priorities 1.2.2 Survey available software 1.2.3 Recommend software choice 2. Development 2.1 Purchase software 2.2 Write program 2.3 Review with user 2.4 Make revisions 3. Implementation
WBS - Change • Most information systems go through several changes before they are complete. • It is important to update all records once a change has been made. • Software packages such as MS Project will update all documents once a change has been made to a work unit.
WBS – As a Mgmt. tool • To monitor progress. • To evaluate cost, time, and quality. • Assign responsibility for each ‘work unit’ or ‘work package’. • To control quality; each work unit is a control point. • It helps communication and documentation. • Has clearly defined deliverables.
WBS - Approach • Top-down – start from the highest level and work your way down to the lowest level. • Good when the project manager can visualize the entire project. • Bottom-up - start from the lowest level and work your way up toward the overall project level. • Good to involve team members and utilize expertise. Time consuming.
WBS – Check list • Work units must be clear and understood by those responsible. • Each work unit must be independent of other work units for ease of allocating resources. • Each work unit must have one personresponsibleeven if multiple individuals work on it. • The sum of work units must result in the project outcome. • Team members must be involved in its development.
Work unit responsibilities • Document and communicate • Use a form; could be a simple one like the table on the previous slide. • Responsibility chart also describes authority. • The chart helps coordinate between units especially for large projects. • Lack of clear responsibility and authority is often the source of misunderstanding, poor coordination, and discontent.
Discussion question • What would you do in cases where deliverables are difficult to define? • Can you use milestones as deliverables? • How does WBS differ from project network? How are the two linked?
