In this article i want to look at some of the areas where those bad deceision are commonly made and see if we can help ourselves to navigate the minefield.
Lack Of Planning Before Kick Off:-
In the real world, the problem is frequently not addressed in the requirements instead its left until the application is built and the the problem start because there is no measure of acceptability.Instead we are faced with managing unchecked client expectations.If instead the requirements identify how the user interface will be rated then we are sitting ourselves up for a much greater chance of success.
Also at the start of the project is the issue of where quality sits in the priority list of project constraints.In the past we all thought of the triple contraints of time, cost and scope with quality being balanced between the three.In the latest version of PMBOK,PMI has moved away from the triple constraints in favour of six projects contraints,time,cost,resource,risk and quality.
This gives a perfect oppertunity to have a conversation with the customer at the outset about where quality fits in that list of contraints.If quality is second only to risk in the customer's list, then we should make project deceisions that put quality ahead of cost, resources, time and scoope.
Apply Pressure To Compress Quality:-
One of the biggest problem faced with project quality is just how willing team members are to let quality slip ahen things get tough.It seems as though its seen as a "lesser" target that can be sacrificed if we get behinf schedule or over budget.
|It seems to be perfectly acceptable to cut corners, especially in processess.This is not usually because the importance of quality is not understood, but rather because the connection between a quality outcomeand doing things the right way is not acknowledged.
This is not always the kind of problem that we can address in the confines of a single project--as project managers we have to ensure that we are creating an environment where the importance of processess is stressed, where the need for quality is paramount and where teams understand that they would not be criticized for putting quality ahead of cost or time if that is what the project demands.
Ofcourse there are situations where it is acceptable to compromise quality, but it has to be concious decision that is approved by the stakeholders.A change in the quality parameters is a project change request and it should be treated that way.
Perhaps the most common example of quality being sacrificed in software world is the squeezing of testing time.The story seems to be the same every time.The code cut off date is missed by a few days in order to get the last features in, but no one extends the delivery dates , they just take time away from quality assurance.
Don"t Learn From Mistake:-
No matter how we plan to deliver quality, there always are occassions where we come upa little short.While its not an ideal situation, it is a fact of life.What still amzaes me is how bad we are learning from our mistakes.Most of us conduct some kind of post-mortem or lessons learned at the end of our projects to identify the areas where we feel that our projects can be improved in future.
And yet, time after time, we fail to learn from those mistakes.wheter it's because of a lack of follow-through to make the recommended process changes, a communication failure or some other reason, that fact is that time and time again we fail to learn from past mistakes and keep repeating them on majority of the projects.
Keep The Communication Inconsistent:-
As project managers, we have to preach the message of quality consistently.If we ever suggest to our teams that it is acceptable to cut a corner or sacrifice qualiy without a formal change ,then we are giving our team all the excuses that it need.For people who are working to deadlines, any oppertunity to relieve the pressure will grasped.We all do it. but that did not lead to the highest quality outcomes.
We need to ensure that our team understands that they will have our support for putting quality first .If our customer or our Stakeholder start applying pressure then we need to refer back to the start of the project where the priorities were determined and it was deceided how important quality was relative to the other project constraints.Customers are free to change their minds, but only by following the process.
Wrapping It UP:-
There are no guarantees that we can achieve the quality parameters that have been st and still deliver on time and budget, but if we are aware of some of the common "mines" that are aout there, then we can atleast improve our chance of being successful.
Lack Of Planning Before Kick Off:-
In the real world, the problem is frequently not addressed in the requirements instead its left until the application is built and the the problem start because there is no measure of acceptability.Instead we are faced with managing unchecked client expectations.If instead the requirements identify how the user interface will be rated then we are sitting ourselves up for a much greater chance of success.
Also at the start of the project is the issue of where quality sits in the priority list of project constraints.In the past we all thought of the triple contraints of time, cost and scope with quality being balanced between the three.In the latest version of PMBOK,PMI has moved away from the triple constraints in favour of six projects contraints,time,cost,resource,risk and quality.
This gives a perfect oppertunity to have a conversation with the customer at the outset about where quality fits in that list of contraints.If quality is second only to risk in the customer's list, then we should make project deceisions that put quality ahead of cost, resources, time and scoope.
Apply Pressure To Compress Quality:-
One of the biggest problem faced with project quality is just how willing team members are to let quality slip ahen things get tough.It seems as though its seen as a "lesser" target that can be sacrificed if we get behinf schedule or over budget.
|It seems to be perfectly acceptable to cut corners, especially in processess.This is not usually because the importance of quality is not understood, but rather because the connection between a quality outcomeand doing things the right way is not acknowledged.
This is not always the kind of problem that we can address in the confines of a single project--as project managers we have to ensure that we are creating an environment where the importance of processess is stressed, where the need for quality is paramount and where teams understand that they would not be criticized for putting quality ahead of cost or time if that is what the project demands.
Ofcourse there are situations where it is acceptable to compromise quality, but it has to be concious decision that is approved by the stakeholders.A change in the quality parameters is a project change request and it should be treated that way.
Perhaps the most common example of quality being sacrificed in software world is the squeezing of testing time.The story seems to be the same every time.The code cut off date is missed by a few days in order to get the last features in, but no one extends the delivery dates , they just take time away from quality assurance.
Don"t Learn From Mistake:-
No matter how we plan to deliver quality, there always are occassions where we come upa little short.While its not an ideal situation, it is a fact of life.What still amzaes me is how bad we are learning from our mistakes.Most of us conduct some kind of post-mortem or lessons learned at the end of our projects to identify the areas where we feel that our projects can be improved in future.
And yet, time after time, we fail to learn from those mistakes.wheter it's because of a lack of follow-through to make the recommended process changes, a communication failure or some other reason, that fact is that time and time again we fail to learn from past mistakes and keep repeating them on majority of the projects.
Keep The Communication Inconsistent:-
As project managers, we have to preach the message of quality consistently.If we ever suggest to our teams that it is acceptable to cut a corner or sacrifice qualiy without a formal change ,then we are giving our team all the excuses that it need.For people who are working to deadlines, any oppertunity to relieve the pressure will grasped.We all do it. but that did not lead to the highest quality outcomes.
We need to ensure that our team understands that they will have our support for putting quality first .If our customer or our Stakeholder start applying pressure then we need to refer back to the start of the project where the priorities were determined and it was deceided how important quality was relative to the other project constraints.Customers are free to change their minds, but only by following the process.
Wrapping It UP:-
There are no guarantees that we can achieve the quality parameters that have been st and still deliver on time and budget, but if we are aware of some of the common "mines" that are aout there, then we can atleast improve our chance of being successful.
No comments:
Post a Comment