Initiating a project: Act 1. Setup, Act 2. Estimation, Act 3. Completion, Investment Risk, Summary
Contents
Status
This is a Draft Specification.
Overview
This scenario illustrates how EMS 1.0 may be used in the process of initiating a project. The main actors in this scenario are a portfolio manager and a software estimator. The scenario is divided into three acts.
In Act 1 the portfolio manager, Pedro Mendelzohn, receives a proposal for a new software development project. Pedro sets up the project by entering some assumptions about its size and duration, and then requests an estimate.
In Act 2 the software estimator, Syd Ethan, receives the request for an estimate and uses a software estimation tool to predict the amount of effort required.
In Act 3 Pedro reviews the effort estimate and applies labour rates to it to produce a cost estimate for inclusion in the business case of the project proposal.
The above three acts are highly simplified and omit the important concept of investment risk. We discuss the uncertainties inherent in the project assumptions and estimates, and describe how these may be represented using probability distributions. The resulting cost estimate is also a probability distribution whose statistical variance is a measure of investment risk.
We conclude the discussion of this scenario with a summary of the interactions between the actors and tools in a sequence diagram.
The details of this scenario are described in the following sections:
- Act 1. Setup - The portfolio manager sets up the project proposal and requests an estimate.
- Act 2. Estimation - The software estimator develops estimates for several alternate ways of running the project and reviews them with the portfolio manager.
- Act 3. Completion - The portfolio manager analyses the cost-benefit-risk tradeoffs and selects the best alternative. This establishes the project baseline for cost, schedule, etc., and completes the process.
- Investment Risk - The uncertainty in estimates is a measure of investment risk.
- Summary - The interactions between the actors are summarized in a sequence diagram.
Add your comments here:
Re: “Software estimation tools enter here by taking the project assumptions as input, and producing a plan as output. Consider the following highly simplified model. In this model the project inputs are size and duration. The output is effort. ” I suspect this is NOT something we will be automating any time soon. Perhaps some specific parts of it could, and that MAY have value. The example misses two critical points that affect whether we can automate through OSLC the “project assumptions as an input to the estimate”:
1) In general, the basic way estimation suites work is subtly different from this – I THINK, estimation suite vendors, please comment: A particular estimation tool has a “model” (I believe that’s the term used) of the input “parameters” (as in “parametric estimation”) needed to produce an estimate of schedule and effort/cost for the project(and perhaps other things). This is the “normal” path, but they can be and are “used in reverse” with contraints, as in this example…you can constrain the project by schedule (‘it must finish in 12 months or less’, or even “it must finish before VS Live 2002 so Grady Booch can demo it on stage with Bill Gates”) or effort (well, maybe team size–“there can be no more than 20 people assigned to this project”) and by using “what if” analysis, see what size/scope can be completed under those constraints with a given quality level or variations on this. Underneath is a relationship between our “four categories of metrics”– size, schedule, effort, and quality. But the parameters in the model–the “assumptions”– vary from tool to tool: Is “language coded in” a parameter, is “industry” (e.g. banking vs. A & D) a parameter etc.?
2) My experience is that these assumptions and contraints are specified in “free form text” within some kind of Vision document. Some project management systems (RPM, CA whatever Niku is now, Primavera I think—first one was LBMS back in the early 90’s!) allow such a document to be an attachment to the project. Other times this is in a requirements management system (RequisitePro, Rational Requirements Composer, I think also DOORS, not, I believe Calibre). And the “project assumptions” are all over the map, and not necessarily inputs to estimation: “We will market this initially in the Southwest United States and France” But in neither case, whether it’s in the project management tool or a requirements management tool is it in a form that can be used for automation. If the Project Management system provides it as a blob/bytestream in the return of a GET method, it will have to be parsed from its original Japanese, Norwegian, or maybe even English to find the inputs to the estimate. Not likely in this round of work :)
However—are the SOME assumptions/constraints we can identify as “general enough” for all estimation tools and can be structured so they aren’t just in text? Probably, but is this a fruitful line of investigation, or will the results of doing so still not be enough automation of the inputs to the estimate to justify it this round of work? This is a prioritization question for our group as much as it is a technical question.
– Main/AndyBerner - 17 Jul 2009
The portfolio/project manager can get a useful, more detailed description of effort from the estimation tool. Type “MetricsEffortEstimateDetail” in the Jump box at the top of this page.
– Main/AndyBerner - 28 Jul 2009
I presume that the Scenario Resource (containing the set of assumptions that become inputs to the estimate) could be extensible (its properties). For example, if a vendor comes up with a model that enriches estimation power by including skills and experience of developers (people) available in a project… that they could add those as properties in the scenario resource
– Main/LucinioSantos - 27 Jan 2010
Category:EMS Primer
