September 28 & 29, 2020 | Virtual
Please login or join to subscribe to this thread
I am doing the exact thing. Hard to find but I did find sample checklists in The PMI Book of Project Management Forms. I like the article "Monitoring the Vistal Signs of Your Project Is It Alive?" by Gopal K. Kapur, Center for Project Management. I think website was VitalSignsWEB.doc. Please send me any ideas. Thank you.
What we use for Program Management Process are:
Weekly Program Team meetings - review schedules, resolve issues, work barriers;
Weekly Problem Identification meeting - review events, drive transition to problem solving;
Weekly Problem Management Committee - review current problem list, criticality and action plans;
Daily Sunrise - identify and categorize problems, focus on daily activities, manufacturing and systems test feedback.
Include in the Quality Plan, Engineering Quality, Software Quality, Service Strategy, Manufacturing Quality. Key Quality Indicators should be readily available (on display in 'war room') - they would include things such as quality targets, growth curves, schedules - whatever you track.
The Quality Management Process should include what you are tracking, how you will track it, and when (and where) your checkpoints are. For instance, engineering plans - when will they be reviewed, critical parameter management, input / output constraints - are things validated and verified. Reliability growth curves, manufacturing growth curves. You need a schedule of what is expected at each checkpoint review to insure a quality product - generally more and more detail as your process progresses.
Hope this helps - I can't get too detailed because our process is proprietary.
I am trying to develop a standard list of metrics to be used on our IT application development projects. I am looking for "good" indicators of overall project health. Of course, we use the typcial cost and schedule based metrics, but I am having a hard time coming up with good metrics for software / product quality. Any ideas other than just number of defects?
Perhaps this is coming from a different direction, but I assume that everyone is trying to improve the quality of their projects. I've also assumed that by high quality, we really mean success in terms of the project (high quality products being accepted by the users, and then used as a part of the benefit generation process).
If the above is true, then a high quality project is based on the acceptability of the products produced by the project, and that is relatively easy to do if you know what your acceptance criteria are as soon as possible (at the beginning preferably).
That means that the quality plan doesn't contain what makes the project acceptable, but how the criteria that have been previously determined will be applied - how will the acceptance / integration tests be done, regardless of the project focus.
When I manage quality in my projects, I am really managing how the products will be accepted. If the products are accepted and used, then you have built products to an acceptable level of quality.
Hope this helps
Sonya, I suggest that you focus on user satisfaction and contribution to operating profit metrics. All IT metrics should be focused on supporting the main objectives of the organization. Get a hold of the business plan. Review the strategic and current business objectives. Then correlate those objectives with IT projects. Management is more interested in IT's ability to leverage its operations to achieve its quest to continually add value to stakeholders. Certainly the quality of code and defect tracking are important but are very difficult to translate into value for the organization. I suggest you create a baseline of user satisfaction with the applications they use, the support they receive and their opinion of the quality of the IT organizational. Then set targets to improve against that baseline. Begin by approaching the user community and solicit their opinions on what IT's success measures should be in context to the business objectives and their ability to deliver value to their stakeholders. I realize this sounds far removed from traditional IT metrics but then again, how many IT organizations are successful in the eyes of management and their customers?
I am a team leader beginning to project a Quality system to improve processes of an IT department. My team doesn't have knowledge neither experience in Quality methodology. I thought first to prepare and give a basic course to them but I had another idea: I obtained a organizational self-evaluation questionnaire about Quality adherence and its explanations. It seems to me that make my team read this material would be a faster way of teaching Quality concepts and principles and, at same time, prepare to apply the evaluation. What my fellows think about this?
The key to quality is measuring and monitoring it. So, a plan needs to be in place. But, the plan is easy because it should be a part of your user testing (email me if there is a question here).
But, how often does one go back to the business case to see what value drivers were discussed? Does eveyone on your team know the value drivers for the project?
Once you know the value drivers, convert it into a quantifiable metric. Sometimes it is easy. When "brand loyalty or user satisfaction" come up, there are ways to measure these drivers without added time or cost.
You should have a round of user testing that is in parallel with QA testing. Get the data and you know you are on course. It's always better to present to a President data than your opinion.
I know it is very late response, but I have seen this only today.
From your Post
"The key to quality is measuring and monitoring it. So, a plan needs to be in place. But, the plan is easy because it should be a part of your user testing (email me if there is a question here)."
It should be ahead of user testing, we cannot ask users to test which is of not good quality so before users testing we need to adhere to quality process
Need some guidance in writing a quality management plan
Please login or join to reply