July 25, 2014
Joanne Nova pointed me to this YouTube video, and she heard about it from Eric Worrall. It’s only about 7-1/2 minutes. Go for it.
This really rings true to me.
July 14, 2014
Scottish Sceptic at http://scottishsceptic.co.uk/2014/07/13/why-climate-engineers-beat-the-climate-academics has conceived a new term (at least to me)–Climate Engineer. He is distinguishing the term “Climate Engineering” with the term “Climate Scientist”–which has been in long-term use, particularly by people who don’t really know what it means. He asks the question
Why is it that people from a general engineering/science background like us skeptics could have known that the academics would get it wrong?
He boils it down to:
Engineers cannot draw an abstract line around what someone deems to be the “science”, and pretend the rest doesn’t matter.
I particularly like his table of comparison, which is worthy of consideration. What does this all mean? To me, it summaries how society has ended up down this blind alley. We’ve mis-placed our trust.
July 1, 2014
The purpose of this posting is to point the way forward for those who are interested in having a simple-as-possible methodology, based on using Microsoft Project or equivalent, for handling the numbers and computations related to planning the cost and schedule for a project.
The goal is to get quickly and easily to:
- Identify what “done” means.
- Identify when “done” might get done.
- Identify how much “done” might cost (to request funding).
- Identify who needs to be involved in getting to “done” (and automatically create an integrated “CTR”).
Here I will tease the reader with the general outline of how to do it and expose the possiblities. In later postings we may more fully flesh out how this works with examples.
This outline assumes you have some familiarity with using Microsoft Project. If not, take the time to read a good book about Microsoft Project. You can use Primavera P6 if you must.
- Assemble a list of the deliverables. A list of deliverables is preferable to a list of the tasks, e.g. the things you have to do to deliver a deliverable. Let tasks be the domain on the people who do the tasks. Focus instead on named deliverables. Remember to include the deliverables you plan for risk mitigation.
- Look at the calendars in Microsoft Project. They probably are ok, but if not then change them.
- Import that list of deliverables (copy/paste works well) into the field in Microsoft Project (or equivalent tool) called “Task Name”. Yes, that may appear to violate the advice in the previous point, but we can’t change Microsoft’s nomenclature.
- Add one project “start” milestone (linked to successors) and one project “complete” milestone (linked to predecessors).
- Use Microsoft Project’s automatic scheduling, and except for the start milestone task, do not enter any start or finish dates. You want Microsoft Project to do the “heavy-lifting” and compute the dates for you.
- Avoid creating more than one or at most two levels of summary task hierarchy, and do not enter blank lines. Keep it simple.
- Fill in the following fields for each “task”:
- Task Type: fixed duration. Let Project compute units based on your input of duration and work.
- Duration, in days, hours/minutes, or whatever. Use elapsed days (“edays”) if the task timeline should ignore non-working days in the calendar.
- ID of successor and/or predecessor. To create the project execution logic.
- Create a Custom Text Field: Gate. Tag each deliverable for the planned project Gate at which the deliverable will be reviewed. Gated project systems are in common use in many industries.
- Create a Custom Text Field: CTR. This is the number or other identifier of CTR (Cost, Time, and Resource) document that will be given to the project’s finance team. CTR’s are commonly used in many industries and show a scheduled estimate of the time estimate of people and other resources. You want CTRs that are integrated with the project plan and not something completely separate–which is what some project teams do–an unnecessary use of their time and could add significant risk to the project. With this approach, generating the CTR is automatic, not added work, and useful.
- Create a Custom Text Field: AFE (Approval for Expenditure) number into which this deliverable will be packaged into the AFE document to seek customer/partner approval for expenditure. AFE’s are commonly used in many industries.
- Assign the list of resources planned for each deliverable. Normally this will be in terms of “work”, e.g. days of chargeable time.
- In the Resource list, provide a billing rate for each resource (per use or per unit of time, e.g. per day).
- Add in key milestones as “tasks”. Link all predecessors and successors for these milestones, e.g. those deliverables which encompass successful completion of the milestone. Fill in the deadline date in the Deadline field if these milestones have real deadlines (as opposed to wished-for dates).
View and Work With Results
- Show the Project Summary task on the view.
- Add the standard field “Cost” to the view to show the cost (which is computed automatically by Project multiplying the resource work times billing rate. Total project cost will be in the top row (Project Summary Task).
- View the Critical Path. This will tell you when the project, as described will be done and what the critical path activities are. If you dislike the computed cost/schedule for your project, then re-plan. Remember, of course, that the Critical Path is not the boss’s favourite tasks, necessarily.
- View the schedule by CTR using the Group feature to group by the CTR custom field.
- View the schedule by AFE using the Group feature to group by AFE custom field to show you when and what to ask your partner(s) and/or customer(s) for funding.
- View the schedule by Gate using the Group feature to group by the Gate custom field. This will give you an indication when to schedule Gate Review meetings with gatekeepers.
- With the Resource Usage view, show the CTR summary. This will be automatically aligned with your current schedule. Adjust the timescale to something useful, e.g. by month, quarter, etc. Daily and weekly CTRs are unrealistically precise. If you must track/plan high-frequency time, use the project schedule, not CTRs, for daily/weekly project control.
- Revise the schedule to better match resource availability
- Revise the schedule to get the dates you seek
- Revise the schedule to get the governance needed (Gate reviews)
- Use probabilistic methods to get the most probable schedule and take care, knowing the uncertainties, when promising project dates. In general, consider promising 70-80% probable dates with customers, and target 30-40% probable dates with suppliers. Align everyone’s incentive bonus schedule (if applicable) to these probabilistic cost/schedule estimates.
- When the schedule is sufficient “complete”, set a “baseline” and track progress to that baseline.
- At intervals (normally for Gate Reviews), update progress and refine with greater precision the remaining schedule.
- Some people prefer (and sometimes brag about) using Microsoft Excel (or equivalent) to do the above project planning to “keep it simple”. This is usually naive. If you are prepared to program into Excel all the algorithms–correctly, of course–this would be ok. Frankly, it is unlikely that the algorithms can be done very easily, nor would most mortals know how to do it. Doing all this work yourself increases the risk you will develop an erroneous cost/schedule estimate for your project. Avoid Excel or other manual methods for this sort of thing unless you are prepared for doing a lot of work–work that Microsoft Project could do for you.