Re-thinking Blog Contents


I stopped posting because of lack of time, but I am re-thinking blog contents. Art and Science is a concept for adding values to anything you do. The science is the learnings acquired through experience and studies and the art part is inborn creativity that is inherent and singular to each individual. This is what makes things unique. For example, if the same requirements to realize a project, using the same methodology, are given to ten different project managers, most likely, there will be uniqueness in the approach and/or results.  

Visualizing the state of projects using geometric figures (follow-up)

Building a project status spectrum

In the previous post entitled "Visualizing the state of projects using geometric figures", it's possible to build a status spectrum for on-going projects with respect to time.

Framework:
  • Define a set of variables: scope, time, budget, priority...
  • Choose a chart in which to display the variables. The chart has to represent all variables.
  • Each variable has a label and a value associate with it.
  • For homogeneity reasons, each value should normalized in order to fit a predefined range.
In this context the only fixed elements are the chart and labels of the variables. All the other elements vary with time.

T(1):Chart(1), T(2):Chart(2), T(3):Chart(3),...,T(n):Chart(n)

The "SUM" of all charts on the same timeline is the spectrum.
Cases:
  1. A predefined finite timeline and variables represents the time frame of a project.
  2. An infinite timeline with finite variable represents an on-going project.
  3. An infinite timeline with infinite variables represents uncertainty.
  4. ...
To be continued ...

    Sizing Software Applications

    Applications are software programs designed to perform functions for users. They use operating system services and other supporting programs to perform a designated function.
    Before developing an application, it would be nice to have an estimate of its size in terms of effort and/or costs.

    Applications can be big and complex or small and simple. An application that needs to interface and interact with users can be characterized by a certain number of elements, such as wireframes, use cases, business rules, data tables, reports, and correspondences. The size of an application can be determined by the number of these elements. The table below describes a hypothetical example.

    Application
    Number of Elements
    Wireframes
    Use Cases
    Business Rules
    Data Tables
    Reports
    Correspondences
    10
    50
    90
    100
    10
    15
    Estimated effort to develop one element of simple complexity level in man-days
    3
    5
    3
    3
    2
    2
    Development Effort (man-days)
    30
    250
    270
    300
    20
    30
    Estimated effort to capture one element during the analysis phase of simple complexity level in man-days
    3
    3
    3
    3
    1
    1
    Analysis Effort (man-days)
    30
    150
    270
    300
    10
    15
    Total Effort (man-days)
    60
    400
    540
    600
    30
    45

    Legend of elements:
    -Wireframes are user interfaces and it’s the way the user communicates with the application.
    -Use Cases describe how a user interacts with the application in a procedural way.
    -Business Rules govern the flow of procedures and data.
    -Data Tables are the data required for the application to perform its function.
    -Reports are printable information.
    -Correspondences can be notes, messages, and emails.

    N.B.- The numbers in the table above do not refer to any industry standard, they are all hypothetical numbers just for calculation and illustration purposes.

    By introducing hypothetical unit rates per day it’s possible to calculate the relative and total costs.

    -Development unit rate per day = $300 
    -Analysis unit rate per day = $500

    Putting data in table format:

    Costs
    Total Effort Development in man-days
    900
    Developers rate per day in $
    300
    Developers Cost in $
    270000
    Total Effort Analysis in man-days
    775
    Analyst rate per day in $
    500
    Analysts Cost in $
    387500
    Total Cost in $
    657500

    All data in this example is hypothetical. For better accuracy, it’s possible to add more variables and factors to this approach.

    Variance At Completion

    In project management a variance is the difference between a planned cost and the actual cost incurred and, normally, this leads to corrective actions. A more general definition of Variance Analysis can be found in Wikipedia and in many other web sites that specialize in this topic.

    Variance Analysis
    
    At Time Now:

    Ei = Initial Estimate (Planned or Estimated Budget)
    Actuals = A = Actual amount incurred
    Et-c = Estimate To Complete
    Ea-c = Estimate At Completion = A + Et-c
    Va-c = Variance At Completion = Ei  - Ea-c
    At New Time (Time Now + T):
    If the variance is high (too much error or discrepancy), then it will be appropriate to assign Ea-c as the new Ei. 

    Hence,
    Ei (new time) = Ea-c (time now) 

    Project Cost Estimate vs. Cash Flow Analysis

    A follow up based on my previous post: analyzing graph of planned project cost against cash flow. 

    A simple comparison can be done using the WBS (Work Breakdown Structure) elements that contain all the tasks (the work to be done) of the project not yet realized. Each task has a cost assumption. Since WBS have a child / parent relationship, it's possible to roll up and summarize the cost information from the lower levels and upwards. The summarized total cost is the project cost estimate (or budget).

    As the project advances, it's possible to validate the project cost estimate against the cash flow (actual cost). A good estimate makes a better forecast of project cost at completion (close to the final actual cost).

    Project Cost Estimate and Cash Flow Analysis
    **The above graph illustrates three curves and is based on a hypothetical project with a number of tasks with an equal amount of work distributed equally over time,

    1. The green curve is the ideal case. In an ideal situation the beginning is usually slow because the project team normally acquires confidence with the project. Once the schedule has achieved 20-30% of the work, the slope of the graph will change and will accelerate due to the confidence and knowledge acquired. At 70-80% the schedule has reached a very good level of control and will continue with confidence to full completion of the project.
    2. The red curve is a representation of an early schedule spending too much money at an early stage. In this case, there is a risk to go over the budget, make mistakes, hence, not completing the project has planned.
    3. The blue curve is a representation of a late schedule. In this case, there is a  risk to work in a hurry toward the end, without the possibility of correcting possible mistakes.
    **Graph to be re-defined.

    In order to compare the project cost estimate with the cash flow at any given point in the timeline of the project, there is a need to know the actual cost of the work done. This data can be obtained from the organization 's accounting system or from the team that keeps track of the financial aspect of the project. 

    To analyze, and not only compare, in order to get more meaningful information of the project cost estimate against the cash flow at any given point, it's necessary to verify how much work has actually been completed to that point. This can be achieved with the Earned Value method. Please see my previous two posts for this topic:

    A simple interactive example of a progress report based on the Earned Value method (part 2)

    Another example of a responsive output graph linked to the previous post (input form) is the  cost and schedule performance index.
    • CPI (Cost Performance Index): greater than 1 means under budget; less than 1 means over budget.
    • SPI (Schedule Performance Index): greater than 1 means ahead schedule; less than 1 means behind schedule.
    In general, ideally, performance index greater than 1 means good and less than 1 means bad. But, each single case must be analyzed to get a better understanding of the situation at a given point in the project timeline, because greater than 1 might not necessarily mean good.

    In this example, there is no relationship between the predecessor and successor instance within the graph, hence, each case is to be treated as a singular case. But, in a real project network diagram where all relationships between tasks have been set to place, snapshots of various patterns can be created. This will give the opportunity to recognize, at a glance, each single case, i.e., the state of the project's situation at a given point (within that part of the project timeline that has been achieved).

    (Please read the "N.B." in the Input Data Form of the previous post "A simple interactive example of a progress report based on the Earned Value method (part 1)".


    (refresh rate every 10 seconds)