Download Monitoring and Control

Monitoring and Control
Summary Report
Step 1 :Project Management Initiation and Planning Documents
For Federal Level
Total Estimated Time
Total Estimated Cost
Names of Provinces / States
Names of Citites
Justification
Company Profile
Objective
Criteria
Requirement
High-level project description, product characteristics
Name
Role
Sponsor
Project
Manager
Team
Lead
Responsibilities
Approve or deny scope change requests as appropriate Evaluate
need for scope change requests Accept project deliverable
Measure and verify project scope Facilitate scope change requests
Facilitate impact assessments of scope change requests Organize and
facilitate scheduled change control meetings Communicate
outcomes of scope change requests Update project documents upon
approval of all scope changes
Measure and verify project scope Validate scope change requests
Participate in impact assessments of scope change requests
Communicate outcomes of scope change requests to team Facilitate
team level change review process
Scope Description
Project deliverables
Product user acceptance criteria
Project boundaries (includes and excludes)
Project constraints
Project assumptions
Schedule to be kept in Microsoft Project 2007.
Deliverables presented in Microsoft Word 2007
May-31-2015
Jun-1-2015
Create and maintain throughout the project a Project Management Plan
document with a revision sheet
Provide weekly status information either in person or by email to sponsor and
advisor according to agreed format. Status information should include
activities completed, activities scheduled for next reporting period, and issues
or assistance needed.
Maintain a running log of your project time (date, time expended, and
activity description).
Establish and maintain current, an electronic project notebook, organized by
Project Management and Product working documents and final deliverables.
Evaluator:
Step 2 :Planning
Step 3 :Executing
Step 4 :Monitoring & Control
Step 5 :Closing














May-31-2015
Jun-1-2015
Jun-2-2015
Jun-3-2015
your selected project planning model : tp-rapid Traditional Rapid
Traditional Rapid Linear Project Management
Project goal(s) are very clear at inception.
Requirement can be "almost " completely established at project inception ... before
planning begins - Project Manager and client convinced of completenness..
Usual sequence/pattern of activity expacted.
Five process groups are executed once.
Minimum changes to scope expacted. Scope change request distrupt the plan.
Team members need not to be co-located.
Time and funding constraints.
Routine / reptitive tasks
Tools and templates are available ir easily obtainable
Designed t compress the project schedule to deliver the solutioin faster.
Planning is still done once.
Dependencies within each set should be high but between each set should be low.
Increase risk due to increased possibility for resource conflicts and reduced time to
analyze and resolve problems.
Increased overhead & time to manage inter & intra feature set issues.
Risk



Does not accommodate change well
o Almost any change request will cause problems with the schedule
Cost overruns
o Client sees no work until late in the project.If problems with testing /
acceptance, more work will have to be done…but most of the budget
will have been spent
Too long before any deliverables are produced
o




Client sees product late in the project. This leaves very little time for change
(if funds are available for the work). The project deadline is near and team
members may already be allocated to other projects.
Requires complete and detailed plans.
o A complete plan may be a waste of time. Every (approved) change request
leads to a revision to the project plan. Danger of plans turning into non-value
added work
More focused on process than providing business value
Focus is completing the project on time, within budget and according to
requirements. Client’s requirements may not actually satisfy the business
need. i.e. the deliverable does not do what the client expected.
Work of the project is compressed into shorter time frame. There is less time to
investigate and implement corrective actions for items such as:
o Scope change
o Resource contention
o Problem resolution
Your Selected Checklist
Quality Monitoring and Control Checklists
A) Checklist for Quality Planning
Getting Started in Quality Planning




Pick the right project (not too large, not too small or insignificant) for quality
improvement
Develop a quality management plan.
Define a quality policy. Establish quality goals and timeline when the goals can be
achieved. Be as specific as possible. Examples:
o Reduce defects by 30%
o Reduce customer complaints by 30%
o Cut down cycle time by 50%
o Good example of a balanced policy: “We will build good ships here, at a
profit if we can, at a loss if we must, but always good ships”. (From a naval
shipyard in UK in late 1800s)
Determine who is in charge and who is responsible for quality.
Identify Customers
•
Identify all relevant customers by analyzing contracts (external customer who is
paying for it), project organization (internal customers who are stake holders), and the
intended product use (the end-user who will be using the product).
•
Prioritize customers. Not all customers are equally important. Compare customers
against each other to develop better understanding. For example, customer A may be more
important than customer B, less important than customer C or equal to customer D. You
could rank customers in terms on a scale of 0 to 10 (10 being crucial).
Establish Requirements
Identify requirements of all relevant customers.
Prioritize requirements from each customer’s point of view.
Prepare customer-weighted prioritization.
Define explicit, measurable specifications for each requirement. For example, how will you
know if a specific requirement has been satisfied?
B) IT Specific Quality Checklist
Break the Projects into Phases/Stages (Macro Analysis)






For Software Development Projects: Breakdown the overall development process into
phases (e.g., life cycle phases such as requirements, design, etc.). A typical software
life cycle is shown above.
For IT Service Projects: Breakdown the service into stages (e.g., initiation stage,
problem definition stage, solution development stage, solution delivery stage, postdelivery stage, etc)
Make sure that the work between the stages flows smoothly without any delays and
wastage of resources. For example, the transition between design and
development/implementation should wait for 2 months for a programmer to be
assigned.
Make sure that the results produced by each stage/phase are of high quality (e.g. no
defects, no reworks, etc.). This means that the results produced by ALL phases/stages
are of high quality and not just the final code that is delivered to the user.
Use project management tools and diagramming techniques such as PERT/CPM and
others to properly manage the project.
Make sure that each stage/phase considers processes, technologies and people issues.
Develop Detailed Work Steps from the Phases/Stages of work (Micro Analysis)
This activity refines the phases/stages identified previously by using the following steps:
Breakdown each stage/phase into very detailed “work-steps” (5 or more steps per phase).
Work steps usually include a list of supplies (e.g., technologies) for a particular job, plus
detailed guidance on how to do the work (e.g., best practices in software development).
Make sure that the work steps and instructions include mundane, day-to-day jobs that must
be done correctly, in a certain order, and without mistakes. ensure that the work steps
conform to the company policies and procedures. Use your written work steps to train
software developers, supervisors and managers. Use the work steps also for testing and for
internal audits.
The main idea is to use your work steps for breaking down jobs and making
improvements. In short, use your work instructions to make sure the work that must be
done, gets done right.
Refine Macro/Micro Analysis based on Frameworks
Refine the work steps (the process) by using Lean approach (i.e., no waste no-where) . Thus
Lean can be used for process improvement.
Define the results produced (no defects, no rework, do it once and do it right) by using the
Six Sigma approach. Thus Sigma can be used for end-product/service improvement.
Use the CMMI approach to start at the right level and then go to higher levels gradually. It is
a good idea to start with CMMI Level 2 and then go higher. Basically, CMMI levels can be
used for “continuous improvement”.
Make sure that a right balance of processes, people and technologies exists throughout (too
much technology and no attention to processes and people is not good).
Familiarize yourself with the available frameworks. Exhibit 1 shows some key resources to
get started.
Selected References on Quality Frameworks
CMMI Main Website (www.sei.cmu.edu/cmmi/)



Six Sigma and Lean Tutorials: The overview and references on Wikepedia on these
topcs are pretty good.
ISO 9000 Quality Management Program weblink (http://www.iso.org/iso/qmp) is a
pretty good starting point for ISO 9000 info.
ITIL official website (http://www.itil-officialsite.com/home/home.asp)
Note: After reviewing these websites briefly and getting an idea, you should do a Google
search for more specific articles by, for example, looking for “LSS versus CMMI”. Articles
comparing the key frameworks are always appearing in the literature.
C) Quality Assurance Checklist
Identify QA Activities

Define activities that will ensure project performance conforms to requirements.
These activities are the main responsibilities of the QA group. The activities may be
actually performed as part of the Work Project activities (e.g., project/service
phases/stages, work steps, etc.) but are still the responsibility of the QA group.

Develop metrics for each activity, i.e. number of defects, number of calls handled in
an hour, etc.
Assemble a QA Plan



Assemble quality assurance activities into a quality assurance plan.
Include what, when, and who.
Include processes, technologies and people in the activities
Example of a QA activity:



Requirement: “answer 99% of hotline calls within one ring”
Assurance activity: Determine percentage of calls answered on one ring during a 48
hour period
Metric: percentage of calls answered in one ring
Sample quality assurance plan:
A QA plan documents all QA activities so that they can be managed and improved
continuously. The following table could be used for a QA plan.
Activity no Requirement Specific
Assurance
Schedule
Responsible
Activity
Entity
A172
Calls answered 99% within Calls answered Done several Joe Mason
promptly
one ring
per 48 hours times a week
D) Quality Controls Checklist




Monitor and measure project performance.
Compare results to specifications.
Take action based on results.
Adopt a continuous quality improvement model, i.e., institutionalize the lessons
learned and use them over and over again.
The following (plan, do, check and act) circle represents continuous quality improvement.