Running Case Task 2

advertisement

1. Please Answer Questions 1 and 2 on Page 112 from the Running Case (Attached) PLS CLICK HERE FOR PG 112 2. Review the outputs by project management process group based on the PMBOK Guide 2004 summarized in this chapter and the outputs used for the JWD Consulting project. Using the three categories you created in Task 1 above, list key recommended outputs by project management process group. Also discuss any other important guidelines that MYH should include in its project management methodology, such as how these outputs should be created. Prepare a two-to four page document with your suggestions.

Recommended Outputs by Category

1) Small IT Projects

Less than the full application of the complete project management process for the project category (selected basic forms, approvals, plans, schedules, budgets, controls, reports, less frequent project review meetings, with less detail required in each.) Internal department planning for a cost account will be made up of individual work packages. A work package will typically have its own budget and schedule. Work packages should be small enough to be executed by individuals or small groups in a single department, and they should be of relatively short schedule duration. A small project might define a maximum work package size as two weeks of effort.

2) Medium IT Projects

A medium project, executed by 2 to 5 staff members. Team can handle some more overhead like Test Plan, Test Case, Change Request, Test Guidelines and the Software Development Plan. Medium projects will assemble 3 to 1 month long work packages that can be appropriately managed and controlled.

3) Large IT Projects

A large project, realized by a larger number of staff members (more than five). Designate an executive Project Sponsor. Assignment of a full-time Project Manager; The full application of the project management process specified for the particular project category for major projects (all specified forms, approvals, plans, schedules, budgets, controls, reports, frequent project review meetings, with substantial levels of detail in each.) Large projects will assemble a bigger work package more than 1 month effort as long as it can be appropriately managed and controlled.

Output Small Project Medium Large

Vision Stakeholder Request Use Case Model Glossary

Guidelines

Must describe the problem, the assumptions and dependencies. Must include user and stakeholder descriptions and product features. Stakeholder requests are logged and managed as Change Requests. Important actors and use cases identified and flows of events will be outlined for only the most critical use cases. Descriptions will be captured as Word documents. Collect, organize and define terms related to the project. X X X X X X X X

Output

User Interface Prototype Architectural proof of concept Prototypes Design model Data model Software architecture document Implementation Model Test plan Test ideas list Test case Product End user support material Project History Document Business case Communications Plan

Guidelines

The user interface prototype is built early, before the whole system is analyzed, designed and implemented. Project risks will be addressed as early as possible using executable architectural prototypes. The Prototype must be significantly cheaper to develop than the real system, while having enough capabilities to support the meaningful functionality. It must not contain: - No code to connect to the layers below. - No Graphics - No standards implemented. - May not have complete data. Has some dummy hard coded data to communicate. The Design Model is expected to evolve

Small

over a series of brainstorming sessions. No separate Analysis Model is created. The Design Model will only be maintained as long as the developers find it useful. This output can be represented an Entity Relationship Diagram. A description of the architecture will be captured which briefly describes the architecturally significant use cases (use-case view), identification of key mechanisms and design elements (logical view), plus definition of the process view and the deployment view. Must describe the steps to be followed to achieve the implementation. Among others, the test plan must include features to be tested and features not to be tested. Item pass/fail criteria, Entry and Exit criteria and test deliverables. These will primarily be harvested from previous projects. Must describe the input, the test sequence and the expected behavior. Source code and executable files for the product. X X X Can be built into the online help. Must include the status sheet for configuration control, the document change records, methods and tools used each phase. The business case is produced and approved by company management. A communications management plan might be very short and produced by one or two people for small projects, while one for a large project might be fifty or more pages long and created by a X X X

Project Medium

X X X X X X

Large

X X X X X X X X X X X X X X X

Risk List

Output

Iteration Plan Review record Iteration and Status assessment Work Breakdown Structure Programming guidelines Project Scope Management Plan Design guidelines Software Quality Assurance Plan Change request Software development plan

Guidelines

committee of key stakeholders Must include all catastrophic risks and risks that consume development resources with their likelihood, impact and contingency plan. Must show the number of iterations expected and how iterations overlap. At a lower level of detail, we can show exactly what is expected in each plan. This is mandatory and deliverable only for customer reviews. Status Assessment is be combined with the Iteration Assessment because the iterations are frequent (one or more each month). The Project Manager will meet with each project team member on a weekly basis to determine progress, and help identify and resolve issues. At the end of each iteration, the team will meet to discuss the project status and brainstorm improvements. The intent is to capture lessons learned. This is followed by a review with the Project Reviewer. Must associate requirements, plans, testing, ownership and deliverables, Provide data for performance measurement and historical databases. Be compatible with how the work will be done and how costs and schedules will be managed. Give visibility to important or risky work efforts. The Programming Guidelines for the project already exist. Must define what is included and what is not included in the Project Scope. The Design Guidelines for the project already exist (harvested from a similar, previous project). Must define the techniques, procedures, and methodologies that will be used by the SQA team in order to ensure software quality. Submit change request, assign change owner and perform impact analysis, estimated and actual effort for each work package. The schedule and resource information will be generated as reports out of Microsoft Project.

Small

X X X X X X X

Project Medium

X X X

Large

X X X X X X X X X X X

Download