This year, the PRICE cost research team is kicking off a major research study on electronics.  The field of electronics changes very rapidly, and we want to ensure our estimation methods are well suited for the latest technology.  While we constantly collect data and update relationships, this study will go above and beyond the norm.  We'll visit modern electronics facilities, interview experts, visit customers to discuss their electronics estimating challenges, and start a major data collection and analysis effort.  In the end, we plan to add many new electronic classifications, reexamine our methods for quantifying complexity, and enhance our custom microcircuits guidance.

We recently toured a modern electronics manufacturing facility to get some hands-on experience.  We walked through the facility, going step-by-step through the manufacturing process while seeing it in action, which led to some interesting discussions.  We talked about a variety of topics, such as cost implications of different quality and testing levels, military vs. non-military electronics, and how they manufacture electronics for different operating environments (extreme temperatures, radiation, dust, etc).

These experiences should prove useful in our research.  Right now, we have many hypotheses for what drives the cost of electronics, such as the topics we discussed at the manufacturing facility.  This is especially true for what we believe has changed in recent history in the field of electronics.  As we collect data, we can test these hypotheses and validate our existing estimating methods and algorithms, or develop new ones.  Our meetings with customers ensure that our final product speaks their language and fully addresses their needs.  We’re just getting started – check back for more updates!

Introduction:

The previous blog covered getting started with the TruePlanning API using VBA. Now it is time to tackle collections. Collections in the TruePlanning API are simply objects that hold a list of objects where all the objects are of the same type.  For example, the Project object contains a collection of the Cost Objects that belong to the project.  In order to use the TruePlanning API, mastering collections is essential, but “mastering” is a bit strong a word given that they are easy to use.

By the end of this blog TruePlanning API users should be up and running with the many different collections that are found in the TruePlanning API.

Setup:

This blog will start where the first blog left and will be based on the Excel file that was created in the first blog.  Perform the following steps to get setup :

1. Open or create the Excel file from the first blog. You should see the following code:

2. Delete lines 9 through 15 in the above code (counting all line from the top). The code should now look like:

3. Create a TruePlanning project and name it “T1”.

4. Give the “T1” project the following PBS:

5. Calculate and save the “T1” project.

6. Make at least three copies of the “T1” via the Project Manager dialog in TruePlanning. This will ensure that the following code will be able to loop through more than one project.

7. Close the “T1” project.

Working with Collections:

As stated above, the collection objects in the TruePlanning API are really just lists of like-type objects such as Projects, Cost Objects, Activities, Resources, Worksheet Sets, Inputs, and Metrics.

The following is a list of the collection objects found in the TruePlanning API:

Notice that the names are all plural. The standard naming convention is that a collection is the plural form of the objects that make up the collection. So the Projects collection is made up of Project objects and the Cost Objects collection is made up of Cost Object objects.

There are really only two ways to work with collections: direct access, which means to get a specific element of the collection based on an ID or name, or to go through each element of the collection.  How you access the contents of a collection depends on the context of the code being written.

For example, a user might loop through all of the projects available in the Projects collection that is contained in the Session object in order to display a pick list for users to select a project. Once a user has selected a specific project, the code could then easily obtain the project by calling one of the direct access functions that are part of the Projects collection and providing the name of the selected project.

Both of these methods will be covered.

Rolling up our sleeves and getting to work:

The following steps will show how to work with the collections found in the TruePlanning API.

Iterating through each element of the collection:

The following code will show how to loop through each element of the collection. There are two ways to do this: indexing based on an incrementing variable, or if your language supports it, using a built in iteration looping mechanism such as a “for each” loop.

Manually iterating by index

This is the time honored, hairy-chested approach to iterating through a collection of elements and is based on the arrays found in most programming languages.  The core idea is that the total number of elements in an array is found and then a variable is incremented in a loop from a starting point (that will be discussed in a moment) up to the total number of elements (determining the total will also be discussed), and each element of the collection is accessed by using the incrementing variable as an index into the array.

To walk through the example of finding all of the projects available to a TruePlanning user, the following steps would be performed:

1. Define a variable to hold an incrementing value that will represent the current index into the collection.   For this example, it will be called “pCnt”

Dim pCnt as Long

2. Define a variable to hold the starting index value of the collection. For this example, it will be called “pStart”

Dim pStart as Long

3. Determine the starting index. Assuming the goal is to start at the beginning of the collection, there are only two options: zero (0) or one (1). The zero may seem odd to some people, but in some programming languages collections, or arrays, use zero as the first index value.  This is the case with collections in the TruePlanning API. Please note that this may or may not be the case with other arrays in the programming language you are working with (such as VB or VBA), but it IS always true with collections in the TruePlanning API without regard to the language being used. This means that our starting value for pStart is zero (0).

pStart = 0

4. Define a variable to hold the highest valid index value in the Projects collection, and then obtain that value from the targeted collection.  All TruePlanning collections have a method that returns the total number of elements in the collection called: Count. So for example,  if a user has access to 10 projects then the Count method  for the Projects collection will return a value of 10 when its Count method is called.

What needs to be noted is that because TruePlanning collections are zero index based the total count of elements will always return a value that is one greater than the highest valid index value in the collection. Using our 10 project example: while the Count method returns 10, the actual list of valid indexes is: 0,1,2,3,4,5,6,7,8,9.This means that if the Projects collection were to be accessed by index using the value returned by the Count method (10), an error would occur.

The result is that when determining the highest valid index value in a TruePlanning index, the value returned from the Count method needs to be subtracted by one because TruePlanning collections are zero index based.

Add the following code:

Dim pTot as Long


pTot = ses.Projects.Count - 1

5. Now that a start and end index have been obtained (assuming 10 projects, the start is 0 and the end is 9), a way to loop through those indexes needs to be employed. Most programming languages have some type of “for” loop that supports looping based on an incrementing variable. The exact formats will differ, but structurally they have the same components: a variable to be incremented, a maximum value for that variable, and some mechanism for defining the code that will be executed with each loop. In VBA the “For” loop does the job.  The variable to be incremented will be “pCnt”, the maximum value is stored in “pTot”. The code to be executed will be all code that is placed between the start of the “For” loop and the “Next” statement. 

Add the following code below the line ():

For pCnt = pStart to pTot

   Set proj = ses.Projects(pCnt)


   If (proj.Name = “T1”) Then

      MsgBox(“Found It!!!!”)

   End If

Next pCnt

6. The code between the “For” and the “Next” keywords is doing the work. Notice how the Projects collection is being indexed through the use of the current index count in parenthesis.  Also notice how the Project object is set equal to an element in the Projects collection through the use of the indexing. Don’t forget the “Set” keyword.  Once a Project object has been assigned to an object the methods on the Project object can be used. In the example the project name is being tested.

7. The following is a complete code listing:

Private Sub CommandButton1_Click()

   Dim app As TruePlanningApi.Application

   Set app = New TruePlanningApi.Application

  

   Dim ses As TruePlanningApi.Session

   Set ses = app.Login("(local)")

  

   Dim proj As TruePlanningApi.Project

  

   Dim pCnt As Long

   Dim pStart As Long

   Dim pTot As Long


   pTot = ses.Projects.Count – 1

  

   For pCnt = 0 To ses.Projects.Count - 1

      Set proj = ses.Projects(pCnt)

     

      If (proj.Name = "T1") Then

         MsgBox ("Found It!!!!!")

      End If

  

   Next pCnt


   ses.Logout

  

   Set proj = Nothing

   Set ses = Nothing

   Set app = Nothing


End Sub

Use built-in looping mechanism

The manual method for iterating over each element in a collection, as described above, provides developers with great control over how the elements of a collection are accessed. The elements could be accessed in reverse order, or the loop could be set at some arbitrary start point in the collection to eliminate searching the total set of elements.  With that control comes overhead. Variables need to be set up correctly, there is the potential to end up with an index value that is not valid and the developer needs to know if the collection is zero index based or one index based. 

Looping over a collection of elements is a very common need so many programming languages provide mechanisms that make this easier. These mechanisms will find the right start point and will continue to loop until the end of the collection, and then exit gracefully. They reduce the work for the developers and reduce the potential for error. Unless there is a specific need, using one of these mechanisms will usually save time, produce safer code and be easier for other developers to understand. 

As VBA is the language being used for this example, the mechanism to be used is the “For Each” loop and it does what is sounds like it will do: it will iterate over each element in a collection or array.  To use it a variable is needed to hold the currently selected element, so a variable of the type contained in the collection needs to be defined. The code executed by the “For Each” loop is bound by the “Next” keyword. All code between the start of the “For Each” loop and the “Next” keyword is executed with each iteration of the loop.

Once set up the “For Each” loop will iterate over each element in the targeted collection until it reaches the end or a special command is given to exit the loop early. You would use such a commend if you were looking for a specific element in the collection, and once you found it, did not need to continue looping through all of the elements in the collection.

To walk through the example of finding all of the projects available to a TruePlanning user, the following steps would be performed:

1. Create the variable that will hold the element items as they are sequentially accessed:

Dim curProj as TruePlanningApi.Project

2. Set up the “For Each” loop. Here the Session object ses contains the Projects collection so it is referenced:

For Each curProj in ses.Projects


Next

3. Now add some code to be executed with each loop:

For Each curProj in ses.Projects

   If(curProj.Name = “T1”) then

      MsgBox(“Found using for each!!!!!”)

   End if

Next

4. Escaping the loop! As mentioned above, it is sometimes desirable to exit the loop before the end of the collection has been reached.  In this example, after finding the project that we are looking for we can exit the loop. Different programming languages will have different mechanisms for achieving this. In VBA the keyword is “Exit For”.  Add the following code just before the “End If” line:

      Exit For

5. That’s it! Notice how much simpler the “For Each” loop was. Admittedly the code for the manual iteration could be streamlined to reduce its “bulk”, but the “For Each” is safer and easier.  The following is a complete code listing containing both approaches to iterating over the collection:

Private Sub CommandButton1_Click()

   Dim app As TruePlanningApi.Application

   Set app = New TruePlanningApi.Application

  

   Dim ses As TruePlanningApi.Session

   Set ses = app.Login("(local)")

  

   Dim proj As TruePlanningApi.Project

  

   Dim pCnt As Long

   Dim pStart As Long

   Dim pTot As Long


   pTot = ses.Projects.Count - 1

  

  

   For pCnt = 0 To ses.Projects.Count - 1

     

      Set proj = ses.Projects(pCnt)

     

      If (proj.Name = "T1") Then


         MsgBox ("Found It!!!!!")

  

      End If

  

   Next pCnt

  

   Dim curProj As TruePlanningApi.Project

  

   For Each curProj In ses.Projects

      If (curProj.Name = "T1") Then

         MsgBox ("Found using For Each!!!!!!!")

         Exit For

      End If

   Next curProj

   ses.Logout

  

   Set proj = Nothing

   Set ses = Nothing

   Set app = Nothing


End Sub

Direct Access of Collections

The example of supplying a user with a pick list of available projects, and then opening the selected project has been described above. The techniques for iterating over a collection would be used for the first part of this example. Each project found could be added to some type of control that would allow a user to pick the desired project.

Once the user has picked the project and wants the project opened, what options are there for getting the project from the collection of projects maintained by the Session object? The entire collection of projects could be iterated over until the desired project is found, but as the user has already identified the project, it would faster and easier to get the project directly from the collection using a direct access method. This can be a big performance savings when the collections are large.

Direct access methods allow users to get elements in a collection using some type of identifier. The two most common identifiers are a TruePlanning API specific ID variable, and the name of the element.  In the previous code examples, the name of the project being sought was “T1” so it is a simple matter to call on a method of the collection that returns the element that matches the identifying data.

Every TruePlanning API object that can be part of a TruePlanning API collection will have an “ID” attribute. “ID” attributes are a string representation of a Globally Unique ID (GUID) and are long and ugly, but helpful because they uniquely identify that specific TruePlanning API entity.   The “ID” values are set by the TruePlanning API so they should be treated as read only.

Coming back to the example of having users pick from a list of projects and then opening a project they selected, when the projects are iterated over to develop the pick list, their IDs could be obtained and stored so that when a user selects a project, the ID for the selected project is known and can be used in a direct access call against the Projects collection. One reason for using the “ID” attribute would be because it is a faster lookup than the name field.

One important consideration when directly accessing elements of TruePlanning API collections: if the data used to identify the element does not match any of the elements in the collection an error will be generated. This means when using any of the direct access methods on a collection the code must be robust enough to handle the possibility that the TruePlanning API will generate an error. In VBA this means using the “On Error” methods, but that is a bit beyond the scope of this blog.

Item by Name

As the name of the target project is known: “T1”. Getting the project with the name “T1” is straightforward.

1. Add the following code before the line “ses.Logout”:

Set proj = ses.Projects.ItemByName("T1")

2. Test what happens if the wrong data is provided to a direct access method. Change the project name to a project name that does not exist. The result will be a “Run-time error: Automation error”:

Set proj = ses.Projects.ItemByName("T1zzzzzz")

Item by ID

To provide an example of obtaining a collection element by ID, a bit of fancy code will be added. Above code was added to iterate over each project and test if the project matched a specific name.  Once the desired project has been found, the ID for that project can be obtained and then used later to get the specific element based on it’s ID.  Admittedly the example is a bit unnatural as the name of the project is known from the start, but that will be maintained to keep the example simple.

1. Declare a variable to hold the ID of the project once it is found. IDs are the string representation of a GUID.  Add the following code after the line “Dim pTot as Long”:

Dim projId as String

2. In the code that executed once a project with the right name is found add code to store the ID for the current project.  Add the highlighted line of code to the existing code block:

   For Each curProj In ses.Projects

      If (curProj.Name = "T1") Then

         MsgBox ("Found using For Each!!!!!!!")

         projId = curProj.ID

         Exit For

      End If

   Next curProj

3. Now that the ID has been obtained, call into the Projects collection to get the desired project. Add the following code below the code block in the previous step:

   Set proj = ses.Projects.ItemById(projId)

   MsgBox ("Current project is: " & proj.Name)

4. That’s It! The following is a complete code listing from all of the examples:

Private Sub CommandButton1_Click()

   Dim app As TruePlanningApi.Application

   Set app = New TruePlanningApi.Application

  

   Dim ses As TruePlanningApi.Session

   Set ses = app.Login("(local)")

  

   Dim proj As TruePlanningApi.Project

  

   Dim pCnt As Long

   Dim pStart As Long

   Dim pTot As Long

   Dim projId As String

  

   pTot = ses.Projects.Count - 1

  

   For pCnt = 0 To ses.Projects.Count - 1

     

      Set proj = ses.Projects(pCnt)

     

      If (proj.Name = "T1") Then


         MsgBox ("Found It!!!!!")

  

      End If

  

   Next pCnt

  

   Dim curProj As TruePlanningApi.Project

  

   For Each curProj In ses.Projects

      If (curProj.Name = "T1") Then

         MsgBox ("Found using For Each!!!!!!!")

         projId = curProj.ID

         Exit For

      End If

   Next curProj


   Set proj = ses.Projects.ItemById(projId)

   MsgBox ("Current project is: " & proj.Name)

  

  

   Set proj = ses.Projects.ItemByName("T1")

  

   ses.Logout

  

   Set proj = Nothing

   Set ses = Nothing

   Set app = Nothing


End Sub

Conclusion:

While the example used in here focused on the Project object, all of the collections in the TruePlanning API behave the same way. Some of the collections may have a few different methods such as adding new elements or deleting elements, but iterating over the collection or going after specific elements using direct access methods is the same.  The example code is a good start to helping users become proficient at leveraging the TruePlanning API.

Introduction:

The new TruePlanning COM Application Programming Interface (API) found in the 2012SR1 release of TruePlanning provides a powerful mechanism for leveraging the power of TruePlanning within custom solutions. Through the COM API TruePlanning projects can be created, updated, calculated and saved allowing for near limitless potential for integration with TruePlanning.  That said it is an “API” which means some programming will need to be done. This discussion is focused on how to get started using the TruePlanning COM API.

Development Environments:

The TruePlanning COM API is written in C++, but is available to any programming environment that can work with COM.  Such environments include Visual Studio for the .NET languages, unmanaged C++, java and Visual Basic for Applications (VBA).

For the purposes of this discussion, VBA from Excel will be used as it is the most ubiquitous development platform in Windows. Anyone with Excel can make use of the TruePlanning API and Excel is the most common application users need to integrate with TruePlanning.  It is also very forgiving and requires the least experience to start creating amazing integrations with TruePlanning.

Creating a TruePlanning project through VBA:

The following steps will prepare the Excel VBA environment to use the TruePlanning COM API (TPCOM), create a project, and then save that project.  Excel 2007 is the version of Excel being used in this discussion. If a different version is being used some of the screen shots may look different, and some of the set up steps will be different, but the code is shown will work.

So let’s get going creating an integration between TruePlanning and Excel!

1. Launch Excel.
2. Open a new workbook.
3. Using “Save As”, save the workbook as an “Excel Macro-Enabled Workbook (*.xlsm)” file.
4. Display the “Developer” ribbon. To do this:
   1. Click the “Windows” button (round button on the top left of the Excel window, with the multicolored Windows icon).
   2. Click the “Excel Options” button at the bottom of the Excel Windows menu.
   3. Check the “Show Developer tab in the Ribbon” checkbox.  (See screen shot following this set of instructions.)
   4. Click Ok.

5. Select the “Developer Ribbon”

6. Click the “Insert” ribbon button. This will display a set of controls that can be added to the Excel sheet.

7. Select the “Command Button” from the ActiveX Controls section of the Insert menu.  It will be the top left item in the bottom half of the Insert menu.

8. Your cursor will become a “+”. Click somewhere on Sheet1 and drag to size the command button. Release the mouse button. As this is VBA, the bigger the button the better!

9. Double click the button to create a macro. This will launch the Microsoft Visual Basic for Applications design environment.  You will see code has been created to handle the event of the button being clicked.

10. Create a reference to the TruePlanning COM object.  In order to use the TruePlanning API, the current code base needs to be told that it is going to be used. To do this we will create a reference. In other programming environments this process will be a bit different, but the result will be the same. In Excel the following steps will create the reference:
    1. Click the Tools menu in the Microsoft Visual Basic for Applications design environment.

2. Click the References option. This will launch the references dialog.

3. Locate the “TruePlanningApi 12.1 Type Library” and check the checkbox in front of it to select it.
4. Click OK.

11. View the TPCOM object in the “Object Viewer”.  The Object browser is a great resource for learning about the objects in the TPCOM API. To use it follow the following steps:
    1. Select the “View” menu in the Microsoft Visual Basic for Applications design environment.
    2. Select the “Object Browser” options, or you can just press “F2”.
    3. Use the pull down in the top left of the Object Browser window to select “TruePlanningApi”.  (See following screen shot.

4. The Object Browser has three panes. The top left pane shows the objects in the API and the top right shows methods and properties of the object selected in the left pane.  In the above screenshot the “Cost Object” object is selected and its methods and properties are displayed in the right pane.
5. At the bottom of the Object Browser window the third pane contains details about the currently selected method or property. In the above screen shot the arguments for the “New” method of the “Cost Object” object are seen. 
6. Click the “X” button on the top right of the Object Brower window to close it, or double click on the “Sheet1 (sheet1)” entry on the left most pane of the VBA design environment. This will return focus to the code for the button that has been created.

12. Create an instance of the TruePlanning application:
    1. The first step in using the TruePlanning API is to create an instance of the TruePlanningApi.Application object.
    2. Add the following code:

   Dim app As TruePlanningApi.Application

   Set app = New TruePlanningApi.Application

3. The above code defines a TruePlanning Application variable and instantiates it (gives it life).

13. Create a TruePlanningApi.Session object.
    1. The TruePlanningApi.Session object represents an open TruePlanning application. To open TruePlanning a connection must be made to the database. The TruePlanning application uses connection information stored in the registry. When using the TruePlanning API the connection name must be provided. The TruePlanningApi.Application object can supply a list of available connections. In this case we’ll use the default connection name.
    2. Declare and instantiate a TruePlanning.Session object. The TruePlanningApi.Application’s “Login” method takes the name of a connection and returns a TruePlanning.Session object.
    3. Add the following code:

   Dim ses As TruePlanningApi.Session

   Set ses = app.Login("(local)")

4. Test the code that was added for validity by using the “Debug->Compile VBA Project” menu option.

14. Create a new project.
    1. A TruePlanningApi.Project object represents a TruePlanning project. It contains all of the components of projects found in TruePlanning including Cost Objects, Worksheet Sets, Local Escalations, a country, and a note.
    2. New projects are created from the collection of projects maintained by the TruePlanningApi.Session object. They are returned from the “New” method on the TruePlanningApi.Projects collection.  The “New” method requires at least a name for the project. Optional arguments are a country and an escalation set.
    3. Declare and instantiate a TruePlanning.Project object:

   Dim proj As TruePlanningApi.Project

   Set proj = ses.Projects.New("MyNewProject")

4. Calling the New method on the Projects collection will create a new TruePlanning project in memory. Note: that that at this time the project has not been saved so if the code were to stop executing at this point, the project would no longer exist.
5. NOTE: If the provided project name is a duplicate of a project name that already exists for the user currently executing the code, the TruePlanning API will rename the project to make the project name unique. It is important to understand this because this can lead to unexpected behavior, particularly if there is code that is assuming a project name.  It is a good idea to check the project name after the project has been created.

15. Display the name of the newly created project:
    1. Display the name of the newly created project by displaying it in a message box by adding the following code:

   MsgBox (proj.Name)

16. Save the project:
    1. Save the project by adding the following code:

   proj.Save

17. Close the project:
    1. When a project is no longer needed the project needs to be closed. It is important to note that closing a project does not cause the project to be saved automatically. It is up to the programmer to ensure projects are saved before being closed. Any changes to a project that were made since the last save will be lost if a project is closed before it saved. Projects that were never saved will be lost for good.
    2. Projects that are not closed are left in a locked state. This can happen when code crashes. If a project is left in a locked state the only way to release the lock is to use the Project Manager dialog in TruePlanning, right click on the locked project and select the “Release Lock” right-click menu option.
    3. To close a project call the “Close” method on the TruePlanningApi.Project by adding the following code:

proj.Close

18. Close the Session.
    1. Closing the session is like closing TruePlanning. The connection to the database is closed. All memory used by TruePlanning is released. Just as it is important to close a project, it is also important to close the session.
    2. To close a session call the “Logout” method on the TruePlanningApi.Session object by adding the following code:

ses.Logout

19. Complete the code by ensuring all memory is released.
    1. It is a good practice to ensure as much memory has been release as possible. In VBA to do this, all variables that make use of the “Set” keyword need to be set equal to “Nothing”. So in this example, the app, ses, and proj variables were set equal to TruePlanning API objects using the “Set” keyword and therefore need to be set equal to “Nothing” after they are no longer needed, which in this case is the end of the click event.
    2. Use the following code to accomplish this:

   Set proj = Nothing

   Set ses = Nothing

   Set app = Nothing

20. Test the Code:
    1. Select the first line in the CommandButton1_Click method.
    2. Press the “F5” key.
    3. This will run the code as if the button that was created had been clicked.
21. Debugging the code:
    1. To debug the code, place debug points in the code by clicking in the grey bar to the left of the code window:

2. When the code is executed and the line with the breakpoint is hit, the code will stop execution and the VBA development environment can be used to examine the code.
3. Pressing “F8” will advance the code, stepping into any functions that are called.
4. Pressing “Shift-F8” will advance, but will not step into functions or subroutines.
5. Pressing “F5” will cause the code to continue running until another breakpoint is hit or until the code complete.
6. Test this by clicking on the command button that was created. Immediately after the button is pressed the VBA development button should come into focus with the line of code with the breakpoint highlighted in yellow.

22. Complete Code:
    1. The complete code should look as follows:

Private Sub CommandButton1_Click()

   Dim app As TruePlanningApi.Application

   Set app = New TruePlanningApi.Application

   Dim ses As TruePlanningApi.Session

   Set ses = app.Login("(local)")

   Dim proj As TruePlanningApi.Project

   Set proj = ses.Projects.New("MyNewProject")

   MsgBox (proj.Name)

   proj.Save

   proj.Close

   ses.Logout

   Set proj = Nothing

   Set ses = Nothing

   Set app = Nothing

End Sub

Conclusion:

In the end the above steps are not particularly complicated.  After working with the above code. the use of the TruePlanningApi Application, Session, and Project objects will become second nature. The above steps, while detailed, really take minimal time to set up and allow users to perform very powerful tasks with TruePlanning.  Questions can be sent to help@pricesystems.com.

Thank you,

PRICE Systems L.L.C.

Recently I have been playing around with the International Software Benchmark Standards (ISBSG) database for Development and Enhancement projects.  And in the interest of full disclosure I admit that I am more than a little excited to have close to 6000 data points at my fingertips.  I will further admit that there’s something quite daunting about having this much data; where to start, what should I be looking for, how can I best use this data to offer some useful guidance to inform software cost estimation.  For those of you not familiar with this data source, the ISBSG database contains data on software projects submitted from software development organizations all around the world. 

Naturally, the first thing I wanted to do was look at Project Delivery Rates (PDR) and try to find some interesting information about what might drive PDR.  Starting small (ish) I filtered the data to eliminate all those data items which the ISBSG has rated as of low or questionable quality and filtered all those projects which had included in their labor totals hours for resources not strictly part of the development team.  I started by trying to trend Functional Size with PDR.  The data was all over the map. In an effort to get some context as to where the good data might be lurking, I began to look at average PDR rates for each Organization Type.  I selected Organization Type because this seemed to be the most granular category that had some structure to it.  Organization Type is intended to indicate the type of organization that the software application is intended for.  Although an Application Type is provided, this value is free form with each submitter choosing their own terminology.  The same is actually true for Organization Type but because of the submission process there was a finite set of responses which could be used as a basis of stratification.  Although the ISBSG data is measured using functional size measures, the list of ISBSG acceptable Functional Size Measures is long and includes IFPUG, NESMA, COSMIC, Mark II, FiSMA, etc.  In order to compare apples to apples my analysis needed to focus on each size unit individually.  I started with IFPUG because this group contains significantly more data points than any other functional measurement category.  I thought I would share some initial findings.  The following table shows the productivity rates for various Organization Types. 

So what does this table tell you?   It certainly needs to be interpreted with care as you will note that for many of these productivity rates the distribution is all over the map.  For industries where the sample size is significant it gives some pretty interesting comparative information.  It also provides some useful information into the types of industries for which you can find data in the ISBSG database (not inclusive because this did not cover all the data points – only the IFPUG ones)  There is also the caveat that for different submitters have different ideas about definitions of things like industry type.  Despite that I think there’s something to learn here.  If you’re interested in data, and who isn’t you should check out the ISBSG’s offerings – they have a pretty cool arrangement using an OLAP interface to allow you to find and pay for only the data you can use.  Check it out at www.isbsg.org !! 

And I'm just getting started - check back for more observations on software productivity!

The IEEE published “Top 11 Technologies of the Decade” in the  January 2011 editions of the IEEE Spectrum magazine.  It should come to a surprise to no one that the Smartphone was number 1 on this list.  The answer to the author’s question “Is your phone smarter than a fifth grader” was a resounding YES![1] 

 In 1983 Motorola introduced the first hand hell cellular phone.  It weighed in at two and a half pounds, had memory capacity for 30 phone numbers, took 10 hours to recharge and had a selling price of $4000 ($8045 in 2006).  The phone was the size of a man’s head and would sustain an hour of conversation before a recharge was required.  In June of 2007 Apple announced that it was launching the iPhone which would basically integrate all of the electronic gadgets teenagers carried around in their pockets into a complete package – phone, web browser, iPod and camera.  The iPhone 5 which should be available by Fall 2011 incorporates NFC technology, an upgraded operating system with cloud integration, music streaming, voice interface, 4G connectivity and an embedded social networking tool. NFC technology makes it possible to use the phone effectively as a credit card – making payments by swiping the phone near a device that can read its information. [2][3][4][5]

The proliferation of smartphones and tablets has led (and will continue to lead) to the proliferation of mobile applications.  And it seems as there are no bounds to the kinds of applications that are being developed for smartphones.  A sampling of some popular applications is listed below:

* Chase Mobile – which allows users to check account balances and review transactions
* Angry Birds – very popular gaming software
* Facebook - allows users to report their status from anywhere
* Yelp – allows users to locate places to eat, shop , etc. along with reviews from local patrons of said establishments

The list goes on but clearly if you can dream it – there’s an app for that (or at least there could be an app for that).  As practitioners in the art of estimation, all this mobile application development leads to the inevitable question of what does it cost to develop mobile apps and how is mobile application development different from more traditional forms of development? 
Mobiles apps can be categorized as either native applications – which run entirely on the device or web applications - with small clients resident on the device which interact with applications running on a remote server.  It appears that in general the web applications are less complex than the native ones, and thus less effort is required to build, test and deploy them.
While mobile application development is still in its infancy so a lot of what is going on in the industry now has a bit of the Wild West feel to it.  This stage of any technology is impacted by learning curve issues which may dampen productivity but at the same time there is the newness factor – where smart people are excited about the promise of new technologies and are willing to work extra hard to make things happen.  So while there is some effort/cost data available for mobiles apps, we must temper our enthusiasm.
Another concern when developing mobile applications is which platform(s) it is being developed for.  If an application is being developed for iPhone, Android and Blackberry the effort is significantly increased.  Although there are elements of the design that can certainly transcend platforms, each of these platforms has its own operating system and development environment. There are additional potential compatibility issues in cases such as Android where there are multiple companies manufacturing devices. Additionally, application developers need to determine which versions of OS for each of the platforms the application will work with.  They also need to be aware of and respect the user interface guidelines developed for the device(s) for which they are building apps.
Mobile applications may need to respond to various forms of external data from sensors, a real or virtual keypad, a GPS, microphones, etc.  They also may need to respond to movements of the actual device as well - so the screen adjusts when the user changes the orientation of the device.  There are also many instances where mobile apps will need to interact with other applications on the device.  Often the mobile application will need to share elements of the user interface with other applications. 
Mobile applications need to be developed in such a way as to limit the consumption of resources.  No matter how good your killer app is, if it drains the phone battery in half an hour no one is going to use it.  Along with all other applications that have access to the Internet, they should be built with a focus on security so that the users data is protected from malicious intrusions.
All of the issues listed above are likely to impact the complexity of the development effort of the mobile application – thus they have the potential to be an important part of the cost equation as well.  In many cases mobile applications are smaller than traditional applications so increased complexity may be offset because the projects and corresponding project teams are small.  Still this increased complexity is important to consider.
Another area where mobile apps are dramatically different than traditional apps is in the testing of the application.  Simulators and emulators exist and can be helpful in some circumstances but they are not always easy to use, effective or efficient.  There are also issues, with some platforms around the maturity of the technology that allows applications to be transferred from the development environment to the mobile device – further complicating the testing process.  Finally there is just the sheer magnitude of making sure that the application functions correctly on all the combinations of hardware, operating system and carriers on which it will be expected to perform.  The cost and effort associated with testing may present significant differences when being evaluated for mobile applications.
Smartphones are here to stay and more and more businesses will want (or need) to develop apps for them in order to remain competitive.  With the technology still relatively immature there is limited data that will help us develop cost models but there is feedback from the field on what issues are most likely to impact costs.  Though the technology is still emergent – there is some data available from commercially based mobile app developments – so at least we have a place to start.
Share your experiences with mobile application development by leaving a comment for this post.

[1] Ross, Philip E., “Top 11 Technologies of the Decade”, IEEE Spectrum, January 2011
[2]  http://www.motorola.com
[3] http://www.apple.com
[4] http://en.wikipedia.org/wiki/Mobile_phone
[5]http://www.ibtimes.com/articles/170418/20110628/quick-look-at-iphone-5-features-as-september-release-date-looks-probable-nfc-camera-8mp-lte-4g-displ.htm

I’m on my way home from the ISPA/SCEA (International Society of Parametric Analysts, Society of Cost Estimating and Analysis) Conference held in Albuquerque this week.  Attendance was very good (2nd best in the conferences history) and as the content seemed especially good this week.  I attended lots of good talks on topics ranging from SEPM (System Engineering, Project Management) cost estimating, Joint Confidence Levels, Software Estimating, Affordability,  Agile software development and estimating for Enterprise Resource Planning Systems.   Of course, just because the topics are good and well presented doesn’t mean I have to agree with everything that gets said.

One particular talk entitled “Function Points, One Size Fits All” got me a little worked up.  It seems as though there is an on-going and completely unnecessary amount of energy devoted by some to convince the software community that we need to settle on a single method of measurement for software.  The author makes some really good, credible points.  Function Points are a much better method of measuring software if your intent is to compare productivity across or within specific industries.  They help eliminate development technologies, programmer inconsistencies and software architecture decisions from an analysis of how productive an organization is at delivering business value to their customers.

Having said this, I firmly believe that sometimes SLOC (Source Lines of Code) are a better tool to help organizations estimate the costs of the software development projects they are planning.  Knowing how your productivity stacks against the industry is great information when you are looking for process improvement or identifying best practices.  But if you want to know how much the next project is going to costor how many months it will  be before you can deliver content, your own history is much more relevant than the industries.  Not that your history can’t be in Function Points – it just doesn’t have to be.  Many of the weaknesses sighted with SLOC – while they certainly can be considered weaknesses) -aren’t really noticeable when working within a certain context.  Within an organization, software development projects are often similar to previous projects, targeted at similar markets and are being developed by similar teams with similar (on average) coding styles. And SLOC Counting processes can be institutionalized within an organization. When this is the case, SLOC counts are just as good, if not better, than Function Point Counts and probably much easier to count since their count can be automated and does not require certified specialists.

The author contends that SLOC is a bad option because it is hard to estimate early on.  I contend the same is true with Function Points - which if the Counting Practices Manual is followed to the letter – one is required to make an assessment of not only all transaction but also all the data element types and record element types.  The author contends that SLOC is a bad option because there is no standard for what a SLOC is.  I contend that the same can be said for Function Points.  Perusal of the International Software Benchmark Standards Groups’ (ISBSG) database shows that there are several different ‘standards’ for counting Function Points – because one standard was not deemed sufficient by many in the community to meet all software measurement needs.

Don’t get me wrong – I do not disagree with many of the assertions the author made, only the notion that one size fits all.  Let’s be real – software measurement is not easy and there are many different ways to approach it depending on the reasons for the measurement and the circumstances around those needs.  Function Points are a good tool to have in your software measurement tool box, so are Source Lines of Code, Use Case Points and user Stories.  It’s true that if all you have is a hammer every problem is a nail.  Fortunately we have many different tools and should feel empowered to choose the right tool depending on the current need.

I was recently asked by a client to provide a synopsis of what TruePlanning offers in response to the Ashton Carter Memorandum – Implementation of Will-Cost and Should-Cost Management. In the memo, the Undersecretary of Defense AT&L listed “Selected Ingredients of Should Cost Management”. It was interesting to note how much capability is provided by TruePlanning to effectively support efficient should cost management. In this month’s blog, I will share with my response to our client with you.

Agile software development practices are predicated on the following tenets as introduced in 2001 in the Agile Manifesto [1]

•  Individuals and interactions over processes and tools
•  Working software over comprehensive documentation
•  Customer collaboration over contract negotiation
•  Responding to change over following a plan

Agile development processes rely on experienced, highly skilled people communicating with clients and each other to deliver software that provides the clients with the most value for the money they spend.  This requires both developers and consumers of software to accept the reality that things will change over the course of the project and that the software that is eventually delivered may not be the same as that was envisioned when the project was first kicked off.

At any given time, the agile software development team is only working on the feature that the customer currently feels is the most valuable.  Estimation is performed by the team (including developers, BAs, QAs and customer representatives) and is only focused on the feature that is currently on deck.  At the end of an iteration, the customer has an opportunity to review the implementation to date and can reprioritize remaining features based on changes in their requirements, market or expectations.  So estimating beyond the current feature doesn’t really make agile sense.

Unfortunately, the fact that estimation doesn’t make sense for the agile team does not mean it doesn’t make sense for the business.  The business needs to see the forest not just the trees.  Customers need an idea when their software will be delivered, businesses need to prep the market for new products and features, businesses need to be able to optimize resource allocations across many projects, etc.   This of course begs the question of how to perform an estimate for software when you really don’t know exactly what software you’re going to build.  As an industry, we’ve been pretty unsuccessful estimating software projects even when we think we have a handle on the end product – how can we be successful with so much uncertainty.

First we accept uncertainty and commit to incorporating uncertainty into our estimates.  Once we’ve made that commitment we are then free to pursue one of many top level estimating techniques to help us get our head around a likely range of values for cost and schedule based on what we currently know about the software project.  Parametric techniques are particularly suitable for this task especially for an organization that has some historical data from previous agile projects.  Parametric estimating models like TruePlanning for Software provide a repeatable framework through which an organization can study their past performances on similar projects (similar number of features, similar market, similar customer, etc) and use what they learn to perform estimates on the project at hand.   The amount and nature of the similarities should guide the amount of uncertainty in the estimate.  Organizational history can be used to map Story Points or User Stories to a size measurement such as source lines of code, function points or user points.  Analysis of performance on past projects can inform decisions about productivity and other project drivers.  This information can be used to drive the parametric algorithms to develop estimates for cost, effort and schedule.

Since we have already acknowledged that we didn’t get the question right, it’s unreasonable to assume that the answer will be ‘the right answer’.  What we do come away with is a range for cost, effort and schedule which will give decision makers realistic data to work with. If we have properly studied our history and thoughtfully assessed uncertainty, we can present these ranges with a quantifiable degree of certainty. 

What process does your organization employ to plan around agile induced uncertainties?

[1] Agile Alliance, “Agile Software Development Manifesto”, Feb 2001, available at www.agilemanifesto.org (retrieved January 2010)

“I think we have an obligation to work with industry to ensure that our suppliers do not just remain world class in defence, but aspire to be world-class manufactures that can withstand comparison to other industries.”

Chief of Defence Procurement, Sir Robert Walmsley

Is this a practical proposition or is it a pipe dream?  The following excerpt from Dale Shermon’s Systems Cost Engineering attempts to make the case that this type of comparison is possible.


Many of the statements in proposals and marketing literature stating the superiority of a company are anecdotal or at best qualitative evidence. It has not been possible to quantify the productivity of industry to demonstrate that one manufacturer is more efficient than another.

In the ship building industry it is possible to benchmark commercial ship yards using a metric called Compensated Gross Tonnage (CGT). CGT measures the complexity of building a ship. It is calculated by multiplying the gross tonnage by the relevant CGT coefficient (calculated by the Organisation for Economic and Commercial Development [OECD]).  However, this is only applicable to this one industry. Other metrics exist in other industries, but what is really required is a single benchmarking technique and measure.

Benchmarking with Cost Normalization.  Forty years ago, PRICE Systems developed a metric that can be used to normalize cost and support the benchmarking practices needed to reach Sir Walmsley vision.  Manufacturing Complexity represents the normalized cost density of an item that has been manufactured. It has two dimensions: technology and productivity. Hence, more than one Manufacturing Complexity can exist. As aircraft are made using different technologies and by different companies, these have various complexity figures. However, if the technology is constant, the only dimension that changes is productivity. As a result, it is possible to compare the efficiency of companies that produce similar technologies.

Supplier Assessment.  One obvious and practical application of this technique is Supplier Assessment. This technique exploits the capability of parametric models to compare organization’s normalized cost density or Manufacturing Complexity. If, on paper, you have very similar proposals, how can you judge which organization will provide the best value for money? Heritage data will determine the level of development that is required and Operating and Support Cost will establish the Through Life Cost, but if these cannot differentiate the proposals perhaps the productivity of the companies should be considered. This is not a simple comparison, but with manufacturing complexity this can be achieved easily.

This process will lead to your suppliers knowing that you are able to control them; they will need more control on themselves. It will enable you to perfect your negotiation skill, leading to more success, as better negotiation material is utilised based on technology cost drivers. A parametric questionnaire is a possible tool to enable proposal validation in minutes.  All this information can be garnered at a very early stage in a project if required, providing better estimating accuracy for the purchased items. Normalization enables a bigger data sample as previous proposals received from the same companies can be compared. This in turn enables the establishing of trends. Are the suppliers becoming more or less efficient? Ultimately, these comparisons can be used to determine preferred suppliers.

Conclusion.  This method of benchmarking a project or company can be used for all environments. With the ability to move across environments it is possible to compare commercial and military organisations equally. Decisions and judgments can be made between Commercial and Military suppliers where no military competition exists.  It is possible to assess the productivity of an organisation or country at System, sub-system and equipment levels. The technique can be used to compare the whole cost or just the labour cost if that is the focus of your efficiency drive.

It is possible to determine preferred suppliers on a justified basis, or alternatively it is possible to demonstrate the efficiency of your organisation when the customer is skeptical about your productivity or your drive to improve productivity.

Finally, many organisations already have a license to use the PRICE models and over 8,000 people worldwide have been trained and are familiar with the PRICE methodology. This is not a new idea, PRICE has been established since 1975, but this new application of an established technique can help decision maker take the right decision regarding source selection cross industry and national companies. Alternatively, it can enable industry to demonstrate, with proof, that they are more effective than other solutions.

1. A round table peer review, where we describe and defend our parametric modeling approach as well as consistency across similar objects/ systems/ alternatives. 
2. Introduction of an independent 3^rd party, not part of the estimating team, who is an experienced modeler. This resource can take the client perspective in reviewing, say, procurement versus cost-of-ownership as well as comparables from similar program experiences.  
3. Take an agile approach where your project leader is the “product owner” who reviews all interim deliverables top-down.  
4. Another option is incorporating a client representative into your pre-release reviews for similar validation testing. 
5. Finally, we pair off internally to verifying each other’s work against the real-time documentation we keep per common templates.  (Available from PRICE Systems, for both hardware and software modeling inputs). They are great visualization tools for internal parameter-tracking, plus external pre/ post model review with customers.

My previous blog discussed a “Should Cost” methodology used by PRICE Systems to complete an analysis. In the article I included a chart depicting calibration results for manufacturing complexities for each weapon system (X-Axis). Manufacturing complexities are a major cost driver within the model. This parameter can be derived from model knowledge tables, generators or from calibration. Many times the calibrated results are simply averaged and used for predicting cost for the new system. This assumes that the new system is very similar in technology and performance as the systems used for calibration. In general this is not the case. Below I discuss how data driven cost estimating relationships (CER) can be developed between the calibration results and a selected independent variable. The CER will then be used to derive the manufacturing complexity, which then matches much closer to the new technology.

Figure 1. Calibration Results for each Weapon System

Since the data was already collected and calibrated within the model, the next step was to identify an independent variable. For manufacturing complexity for structure, thrust was selected. However, other variables could have been selected.  Maximum take-off weight, range, ceiling, empty weight, thrust per pound, or speed were all candidates for an independent variable. For manufacturing complexity for Electronics, frequency speed was selected as an independent variable. Again there are many potential candidates for an independent variable for electronics. 

The next step was to graph and complete regression analysis. Figure 2, depicts the results for manufacturing complexity for structure, and figure 3, depicts the results for manufacturing complexity for electronics.  I normally select a power function when regressing data. One could select any function except linear. Linear regression does not always work very well and as a practical matter technology advancements are rarely linear. 

Figure 2.  Manufacturing Complexity for Structure

Figure 3. Manufacturing Complexity for Electronics

Using the above equations now require information be collected on the aircraft thrust requirement for structure, and frequency speed for electronics. These requirements are then used to calculate the appropriate manufacturing complexity. This approach insures that the cost estimate now match up with the requirements. 

The next time you need to complete a cost analysis, talk to one of our expert PRICE Solutions consultants for help.

PRICE Systems recently accepted an assignment to complete a "Should Cost" estimate for a U.S. ally on a weapon system. The estimate included not only analysis on production costs, but also should cost on various operations and support costs. The only information provided by the client was quantity and time frame for production. A major ground rule for the estimate was that all data specific to the weapon system must come from publicly available information.  For example, mass, manufacturing process, and learning curve information must come from the public domain. 

After reviewing the scope for the estimate, we decided to also collect data on four similar weapon systems. This would allow us to provide not only a “Should Cost” estimate, but additional information to support the estimate. 

The initial task was to collect data on each weapon system. Pertinent model inputs were collected from various public sources. Flyaway costs were collected for each weapon system and used as the cost input for calibration. Manufacturing complexity for structure and electronics were the key input values solved for via calibration. The calibration results are displayed in a line graph, depicted in Figure One below.

Figure One. Calibration Results for each Weapon System

We then translated all calibration input data and calibration results into a predictive input file. Estimates were completed for each weapon system. All results were reported in the form of a graph depicting average amortized production costs, average flying hour cost, and average operations and support costs for each weapon system. 

The assignment could not have been completed without the capability of the PRICE Models. Model calibration was a critical task. Only a few pieces of data were required: quantity produced, production schedule, and mass. 

The model’s capability to solve for values for manufacturing complexity and a graphical depiction of the results enabled the client to quickly understand the results even though some of their personnel were not familiar with the PRICE models. Do you have a question about should cost?  Post it and we'll do our best to answer your question.  Need help? Contact one of our experts for assistance.

In the February 2011 issue of National Defense, I was struck by the article “Uncertain Path Ahead for Military Truck Fleet”[1]. This article centered on the best strategies for modernization of the aging fleet of Humvees. The recapitalization of 150,000 Army and 25,000 Marine Corps Humvees is creating a “fix or buy new” dilemna for decision makers. According to the article, GAO analyst Michael J. Sullivan should include a “cost-benefit analysis that would minimize the collective acquisition and support costs of the various truck programs, and reduce the risk of overlap or duplication.

The TruePlanning model is an excellent framework to conduct the vigorous cost-benefit analysis called for by GAO.  Having recently completed in-depth AoA’s on two high profile programs, outstanding results were obtained and used by decision makers at the highest levels.

Conducting an AoA using the TruePlanning framework and models would introduce the type of rigorous analytics needed to support the DoD’s vehicle strategy while satisfying the GAO call for cost-benefit analysis. Within the model, each alternative could be structured for both its acquisition and lifecycle profile. This would contain Humvee recapitalization profiles for armored, unarmored and even vehicles that have surpassed their economic useful life. In addition, other alternatives such as JLTV, MRAP, next generation Marine Corps personnel carriers and new production Humvees could be modeled as well. Cost-benefits can also be modeled via TruePlanning’s specialized benefit objects.

In sum, complete force-structuring analysis can be accomplished within the TruePlanning framework. Coupled with optimization tools such as ModelCenter, decision-makers have an analytical way of removing uncertainty for modernizing an aging truck fleet balanced with economic realities.  If you are interested in how force-structuring can be accomplished within TruePlanning, I would be happy to share with you a paper a presented at DoDCAS last year on the subject. Just a post a comment with your request.

My June blog entry suggested the use of parametrics in real-options valuation. This month, I’d like to offer the generalized use of our type of modeling in valuing tangible assets. 

Typically, fundamental analysis evaluates the intrinsic value of securities. I won’t attempt to compete with Warren Buffet here. But it is certainly the case that a company, or portfolio of securities reflecting many companies, is based in part on the market value of its product assets and their potential for future earnings, as well as other objective and subjective considerations.

In parametric estimation, we take a top-down approach to developing models of estimating ultimate acquisition and ownership costs. In the case of the former, I’d argue that we can readily… and uniquely… estimate operating costs for companies developing and selling, say, technology-based products.  Marketing can determine pricing, based on their competitive landscape analyses and market-demand for unmet needs. 

We are in an excellent position to complete the forecasting of earnings (and hence, discounted cash flow) using our parametric methods to evaluate a product-system’s should/will costs. Anyone who does detailed bottoms-up budgeting for “go to market” expense, as well as production delivery, would find value in our modeling.  

And again, once estimated costs are subtracted from revenue forecasts, the netted estimate of earnings and cash flows will allow for traditional market value assessment of this asset or entity. For example, your organization needs to compare economic potentials of emerging new software products. There are no balance sheets. There are no income statements. Yet. 

Now your sales and marketing function has a good independent sense of revenue opportunity. So it’s left to you to estimate the costs of developing and delivering. Independent parametric estimation is the answer. No idea on sizing, either SLOC or function points? No problem. 

Data-driven True Planning has years of data modeling that allow you to run application-specific calculators. In addition, you can take advantage of calibrating actual data from similar projects. Likewise, this process of valuing assets holds true for IT infrastructure products as well. Cloud computing, SAAS and ERP are all further examples of where new IT/software products are emerging… and need estimating as well as financing via valuation.

I think parametric estimating has significant value commercially in the estimation of value of future product assets, and consequently their companies and associated securities.  What do you think?

Last week I gave a webinar which detailed the PRICE perspective on Should Cost & Will Cost Management. The responses I have received have been very positive and also informing. For those of you who could not attend you can view the recorded version of that webinar here.

Below is a brief summation of that presenation and some key takeaways.

The Under Secretary of Defense issued a memo late last year. The thrust of the memo was the current need for greater efficiency and productivity in defense spending. His guidance contained 23 principal actions for improving the efficiency of the department organized into five initiatives: (1) Target Affordability and Control Cost Growth; (2) Incentivize Productivity and Innovation in Industry; (3) Promote Real Competition; (4) Improve Tradecraft in Services Acquisition; and (5) Reduce Non-Productive Processes and Bureaucracy.

One of the principals outlined in the first initiative is the idea of driving productivity growth through Will Cost / Should Cost management. In my view, Should Cost is "the realm of the possible" and Will Cost is "the domain of the probable". Simply put Will Cost is a forecast of a program’s cost …” based upon reasonable extrapolations from historical experience.”[1] Whereas, Should Cost is an analysis of what the program ought to cost given concerted efforts in economy and efficiency by the contractor. “A should cost analysis results in an, …” Approximation of a contract-price, developed by the customer’s accounting, engineering, procurement, and other costing staff.” [2]

Should Cost analysis for DoD was first applied by the US Air Force in the early 1960s. Over time this practice matured to where in 1972 it was declared “A Multimillion-Dollar Savings” in an article written by Major David N. Burt in the Air University Review (September-October 1972). Major Burt describes the evolution of the practice commencing in a thorough discussion of a “new” alternative approach. He goes on to describe a five phase approach spanning one to four or more months consisting of a very large team which includes actual on-site (contractor) investigation of contractor practices and operations. There are issues associated with both of these concepts.
 
First, a Will Cost estimate is a business as usual view which contains all of the characteristics of both good and bad production and management practices. Estimates based on Will Cost have the effect of perpetuating previous inefficiencies by providing a flawed benchmark. Secondly, a Should Cost analysis as described by Major Burt is both time consuming and costly to implement. Furthermore, Secretary Carter, in his November 3, 2010 memorandum to Military Departments and Directors of Defense Agencies declared his desire …”to establish “Should Cost” targets as management tools for all ACAT I programs… and to establish by January 1, 2011 …”’Should Cost’ estimates for ACAT II and III programs… for component MS decisions.”

Clearly Secretary Carter is serious in regards to achieving productivity growth and soon. However, given the timelines, the cost of a traditional “Should Cost” analysis, and the problems associated with a “Will Cost” approach,  how can the Military Departments and Defense Agencies meet the “beyond objectives” outlined in the November 3rd memorandum?

One solution may be utilizing a parametric approach. A parametric estimating approach will reduce the time and resources required while also providing an external benchmark of industry standards for similar systems. Given the pace with which agencies are expected to move its probably an approach many should consider.

Bob Koury
Senior Research Analyst, PRICE Systems

Today, PRICE Systems, Senior Research Analyst, Bob Koury, will be presenting on Will Cost/Should Cost management.

The presentation will focus on two main requirements mandated in the Ash Carter memo (mentioned here several times): Developing Should Cost/Will Cost targets and establishing Affordability as a requirement.  An example will be provided of how parametric estimating models were used to establish “Should Cost” targets and how they can be used by a budget authority (government or Industry) to be an informed consumer of contractor or sub-contractor bids. The demonstration portion of this webinar will focus on a process for using a parametric estimating model to produce the reasonable affordability targets.

To sign up for the webinar go here: https://www2gotomeeting.com/register/142598427

In last month’s blog I wrote about Ash Carter’s (Under Secretary of Defense for Acquisition, Technology & Logistics) Memorandum for Acquisition Professionals, Better Buying Power: Guidance for Obtaining Greater Efficiency and Productivity in Defense Spending (14 September 2010).

I concluded the TruePlanning unified framework and comprehensive cost models, is a tool very well suited to provide the types of analysis outlined in the memorandum. In terms of Should Cost and Independent Cost Estimates (ICE), TruePlanning estimation software provides the industry standard capability to conduct Should Cost and calibration (actual program history) for ICE. Most interestingly and to the point of the Carter memo, TruePlanning has the capability of breaking the “self fulfilling” prophesy of business-as-usual.

On November 3^rd, Ash Carter issued a follow up memorandum outlining specific actions to implement the September 14^th Guidance. For this month’s post, I wanted to point out some specific comments about Milestone A and B actions and specifically how TruePlanning can help.

At Milestone A the memorandum specifics establishment of an “affordability target to be treated by the Program Manager (PM) like a Key Performance Parameter (KPP)…This analysis should show results of capability excursions around expected design performance points to highlight elements that can be used to establish cost and schedule trade pace.

At Milestone B, the memorandum requires ”a system engineering tradeoff analysis showing how cost varies as the major design parameters and time to complete are traded off against each other.” Thus, Integration between parametric cost models and performance models is needed to allow full exploration and optimization of the trade space, treating cost as another design parameter

Did you know that TruePlanning through its integration with Phoenix ModelCenter is a powerful tool to provide exactly this type of analysis? ModelCenter contains a native plug-in to interface with TruePlanning directly. Through the ModelCenter interface, analysis can easily perform Design of Experiments (DOE), Carpet Plot Analysis (trading performance KPP’s against cost) and Optimization Analysis.  If you are interested in seeing some examples, especially system engineering trade off analysis, please get in contact with me and I will send you a few presentations.