Every manager knows that, given the quality-deadline-budget constraints, sooner or later he needs to "adjust" one in order to complete the project within the other two - especially if they are tight. Every project should find an acceptable balance between the three, a balance based on a trade-off limit established with the involved parties before the slippage occurs.
A question each PM should ask is: "In the most likely case that something goes wrong, what are my limits? What can I adjust?" The deadline and budget being rather fixed, given the market window opportunity and the sales forecast, is it quality then? It shouldn't be, as long as the quality target is within the application domain (e.g. no military constraints for a domestic use). Especially in our times of crisis and fluid markets - community sites, experts within reach, reviews, high competition-, lowering the standards of the product could mean a major drop in sales, or, even worse, brand compromise.
There is, however, an escape - the number of features. I can almost certainly say about every software project that is has at least one not-so-needed function that can be dropped off in case of emergency. What is there to do then? Well, I think the key word is prioritize: selecting that set of features that constitutes the core, that set that defines your project and makes it stand out of the crowd. These should be quite a few and be given the highest priority. Assigning a lower priority to the others, based upon business value and duration and making sure that you can complete the core and do as much of the rest as possible, without compromising integrity and quality should do.
As a rule of thumb: always try to make sure that a complete and coherent working product can be delivered at the highest acceptable standards, no matter what happens, and that all the stakeholders understand and agree with the compromises. And one important thing to remember: late cuts lead to inconsistencies, therefore cutting is something that must be prepared in advance. Ideally, all the times, the product should be coherent and marketable.
2 comments:
The thing is no matter what compromise you do, quality always suffers. Here are 3 scenarios:
- The project goes overbudget, you have to reduce the number of resources: reduce the quality.
- The project is behind schedule, let's finish fast, let's reduce the quality.
- We can't meet the customer specs, let's reduce the quality.
So it's always quality + another constraint (sometimes it's only quality, but this is rarely happens).
Note: You might want to look at this series of articles: six constraints: an enhanced model for project control, it's interesting.
I suspect that it is largely based on how quality is defined. If the term encompasses the number of features then it suffers, indeed. However if one can prioritize the features and do only the most crucial ones, quality in terms of mostly bugs can suffer less and still keep the client happy (Keno customer statisfaction model) if his expectancies are properly managed. At least for software development, I strongly belive that agile methods like SCRUM or XP provide a good framework for delivering a solid product.
Thanks for the link.
Post a Comment