"perfer et obdura; dolor hic tibi proderit olim"
More often nowadays I see it happen that suppliers who fight for a contract give presentations which in short suck. More often nowadays I see it happen that the clients are not fully aware that those presentations suck. And more often nowadays I see it happen that the supplier who gets the job doesn't get the job done because its presentation and thus its insights did - indeed - suck.
How can we be sure that the supplier knows what it must do and what the project consists of? In the old days we used the good old (Nesma) FPA to check the amount of function points of a system to build. In these days I do not see this happening anymore, only within the really big projects. But everything under the million seems to be target for sloppy planning.
How can a supplier be sure how much time it takes to build something without proper function point analysis? I used to work a lot with Cocomo II. It's not the holy grail but what it did and had was analyzing a projects function points compared to a big database wherein we could find similar projects. True, if you didn't know what you was doing, the outcomes sucked also. But, if you knew what you were doing, the outcomes were very interesting.
You can do FPA at three levels: indicative, global and detailed. When project managers came to me for estimations about projects, I gave them three plannings. I gave them an indicative, global and detailed FPA planning on the discovered function points of a system. These function points were surrounded by the Cocomo constructive cost model elements based on function points and the proper chosen programming language.
Indeed, this does not give you the certainty that the planning 100% fit the bill, and often the project managers were choosing the indicative to communicate with the client. But, it is far more responsible than what I see happening in these times. They come up with global Use Cases, Story points, System parts and what not and start doing the math on these very global functional system elements. People, that is not enough.
To be honest: I use Use Cases and User Stories myself all the time. Also to get a clear picture of the system to build. A nice document about this way of estimating your to build system is included in this post. But, it is not enough. Although this guy Clemmons is doing a real nice job, I prefer to go a bit deeper and take the defined Use Cases and split them up in function points; whether they be indicative, global or detailed. This gives them a more realistic body.
Having said this I think that it must be clear by now that the planning of the system to build is a serious business and not something you can do in a global functional and commercial presentation. It is not enough when a supplier answers the project questionnaire all positive. That gives us not enough proof that they understand what they have to do. At least we want the suppliers to have a clear picture of the complexity of the system to build and the knowledge of how many functional elements the system has.
Another very interesting thing is the quantitative risk analysis for project managers. Included is a paper about it. This paper is the final report of the RAND Internal Research and Development (IR&D) project “Risk Management and Risk Analysis for Complex Projects: Developing a Research Agenda.” The aim of the
project was to survey how quantitative risk management and risk analysis methods were applied to the planning and execution of complex projects, particularly those which planned to utilize new and untried technologies. One recent RAND study indicated that such methods, while widely advocated, were not used to plan and manage a critical government satellite development project. This paper recommends several research areas in which RAND could contribute to evaluating the utility of these methods and improving their applicability.
Document : rand_wr112.pdf (included)
What it shows you is that this quantitative risk analysis means serious business and especially when things are new. When I relate it to SharePoint and Azure for example, then we are talking about new things. When we rig up complex Azure SharePoint farms, combined with BizTalk Azure farms and Navision Azure farms which are interconnected with on premise farms with interconnected AD's, databases, resources and what not; then we are talking about serious business. It is incredible to realize that many suppliers approach these kinds of projects without doing the proper FPA, UCP or quantitative risk analysis.
To round things up, I found a nice document about integrated qualitative and quantitative risk analysis of project portfolios submitted for the "Enterprise Risk Management Symposium"of April 2013 in Chicago. Project portfolio risk management and risk analysis is one of the critical components of ERM. Organizations measure and analyze risks associated with projects, project portfolios, and programs. Such risks can be related to project schedules and affect project durations, completion dates, costs, resources, success rates, etc.
Document : erm_2013_paper_virine.pdf
This integrated qualitative and quantitative risk analysis should somehow be related to upcoming projects for organizations. Just as you can do an indicative, global and detailed FPA or UCP planning; you can also do a indicative, global or detailed integrated qualitative and quantitative risk analysis which depend on the complexity of the project. Not doing it at all is asking for trouble and makes the project more a gamble. The outcome of the project in such a case is more like a poker game of black jack. Don't be surprised if you loose and get hurt.