What is true sense of quality in IT projects?

Hi all

Happy New Year 2009!!!

I am seeing some project management techniques and most of them are focused on quantitative approach.

How we can measure & manage knowledge & creativity in quantitative units? How much it is effective to achieve true sense of quality?

Is any project management technique is based on qualitative approach?

Please share your experience and opinion. It will be great help for me.

Thank you very much in advance.

Regards

Ram

Ram Srivastava

Team (Innovation, Marketing & Execution) Lead @ YMSLI. Open Source, LAMP, Agile, CMMI. Success story in recession!!

I have this discussion pretty regularly. Typically, PMs and PMOs become focused on budget and schedule to the exclusion of any other metrics or considerations. As indicators of general project health, they’re not bad. But when organizations start equating them with “project success”, We end up with projects that are deemed “successful” but often fail to deliver any business value. It also leads to a number of bad behaviors such as throwing warm bodies at late projects, skimping on QA, poor risk management, code-like-hell programming, requirements disconnects, poor documentation and traceability, etc. Personally, I believe that there is no greater threat to project success than focusing on the wrong metrics. The approach that I’ve generally tried to promote is a process-centric one. Establish the right processes and behaviors to capture and manage requirements, maintain stakeholder involvement, control changes and scope creep and to ensure proper QA throughout. Then measure process compliance and customer acceptance at each stage (quantitative) with customer satisfaction (qualitative) shortly after major milestones. In addition, when scoping the project, determine what the customer’s real KPIs (key Performance Indicators) and KGI/CSFs (Key Goal Indicators/Critical Success Factors) are and include them in the tracking processes. Having that discussion can be surprising. Unfortunately, you need to have somewhat mature processes to be able to implement something like this and you also need some sort of neutral oversight to review process exceptions to determine if the exception was appropriate or just laziness. A project shouldn’t be penalized for bypassing process steps that aren’t providing business value. However, those decisions need to be made consciously and with some form of review/audit to keep people honest.

In rank order, what are the criteria you use to drive prioritization of the various projects and programs in your portfolio?

Question received via Gartner Symposium Forums

1. Discretionary vs Non-Discretionary

This requires the discipline to accurately categorize your projects. “Non-Discretionary” simply means that if you don’t act, something in the organization will break. Whether it’s a process, tool, or technology, there is a better than even chance that a failure to approve the project will result in damage to your business. This doesn’t mean that you miss an opportunity or you fail to make a sale. It means that you will suffer some sort of loss or degradation of your operation. A technology refresh is discretionary unless something is very likely to fail or put you into a position where you will be harmed by not upgrading.

Most organizations don’t have the stomach to draw the line that distinctly. “Non-discretionary” becomes “politically prudent” and “Discretionary” becomes “good to do, but nobody is really pushing for it”. The problem is that if you follow that model, you’re very likely to start cutting into Non-discretionary projects when money gets tight and there’s no way of knowing what was *really* critical to your survival. By definition, a non-discretionary project is something that has to be done or some other risk mitigation takes place. It can’t simply be rejected.

2. Required timeframe (is there a critical window of opportunity or risk?)

This applies to all projects. Again, many organizations put arbitrary schedules and timelines in place which undermines the ability of the portfolio manager to understand what the “real” time constraints are. When you establish your portfolio, there needs to be a clear distinction between a “requested date” and any actual time constraints on the project. Unfortunately, most tools that I’ve worked with don’t make that distinction.

3. Benefit (or risk avoidance)

Once you’ve determined the criticality and hard time constraints, then you can start looking at benefit realization or risk avoidance. Most organizations start here by prioritizing strictly based on ROI. However, the PMO and the project teams have to address the critical time-constrained projects in the margins to keep the company running. If your house is on fire, you need to deal with that first and not worry about selecting new carpets.

4. Cost/Cash flows

This and the next category are what’s going to control the actual flow and scheduling of your projects. Once you have your prioritization sequence in place, you can start allocating your cash flows for the next month, quarter or whatever planning calendar you work with. This allocation will end up being iterative with the next category. However, it’s important to recognize that resource constraints can often be addressed with external consultants or some other form of outsourcing. Budgetary constraints tend to be firm.

5. Resources

Once you know what you have to do, the windows for doing it and what money is available to do it, resources are the final gate. If you don’t have resources in-house, consider planning for the development of new resources in-house (time permitting), acquiring staff or outsourcing as appropriate. While this is the biggest practical limitation on executing your project, it’s also the one where you have the most flexibility.

Other factors such as strategic fit, synergies between projects/programs, missed opportunity costs, balancing the availability of critical resources, etc. all come into play as the portfolio is optimized. In addition, this is a recursive process. So sunk costs, project performance-to-date, and other metrics are also included in subsequent review, but may not be part of the official “checklist”. Instead, they become factored into the other elements like the anticipated benefits, risks and risk avoidance.