Yesterday I was teaching a class on project management and used a baseball analogy to explain the role of the project manager and that the project manager is just one of many team members that must perform their job in order for the project (team) to succeed.
Last week I distributed a lessons learned document to my project sponsor, project team and end users. The project kicked off about four months ago and we have converted two of eight warehouses from one warehouse management system to another in that time frame.
The organization I am engaged with does not have a project management process in place so lessons learned is a new concept to them, however at a recent project status meeting one team member asked, “Don’t you do lessons learned at the en
I just finished a project assessment at the request of a client who said her top project was the implementation of a new system. The project was approximately 18 weeks behind schedule when I was asked to conduct the assessment. Although there were about five major problems with the project’s health such as lack of executive sponsorship and poor allocation of resources, the most critical issue that needed to be addressed was project control.
This week I was discussing the need for milestone visibility. Strange topic to be discussing, but it happened! The conversation begun as I was making a point to allow the PM tool (in this case MS Project) to calculate the milestone date based on the tasks dependencies and how easy it was to have this information available and updated. My audience questioned why should the project team need milestones!
Better to have questioned why do we need to breath.
Milestone visibility to the project team was view as a side issue. The team needs to focus on the technical work and not on the management issues like budget and dates!!!
This out-dated view of the world is still alive.
Currently not to have any kind of process (like milestone updates) on a project so the project team can have as much time as possible to make the technical work can lead only to one outcome. Soon or later the time spend on the correction of error/quality problems is going to increase due to errors made early on the project making the project end-date to be missed.
Imagine this, only the project end-date is set. The team starts to work and it actually releases the product on time but with many problems due to low quality control so the end date can be reached. Because no intermediate control points where established no prediction of this situation was made.
As we all know errors are easier and cheaper to correct early on the project than later, for this reason processes as milestone control can help visualize schedule variances and make the team more accountable for there performance early on the project.
Compare the no process approach with a team that early in the project establishes a set of milestones and control it early. The team will follow up any variances and take any corrective action so the target dates are accomplished not only the end date. This will in the long run increase quality and project visibility to the outside stakeholders.
Currently I am mentoring three project managers who work in a project management office for a financial services company. The PMO has a meeting every two weeks with the executive team to review strategic investments. One major problem that the PMO team has is poor attendance by the executive team at the steering committee meetings. The chief operations officer, chief information officer and vice president of quality attend most of the time. The chief executive officer and chief financial officer
Does a project charter need to be constructed for every project that is small and usually executed by the organization?
Although a project is a unique endeavour there are in some organizations certain project types that are always executed (for example in a telecommunication industry the expansion of capacity of communication nodes is always seen as a good business opportunity and the proposal work is always done).
The charter in this case is a pretty standard document stating the business opportunity and the usual constraints that the project must take into consideration. Only a certain level of review needs to be done by the sponsor to acknowledge that the unique characteristics of this project are stated in the charter. This is a very quick task but with a very high return since at this phase the sponsor can alert the project manager for risks that must be accounted for during the planning phase.
As we all know as soon as a potential problem is uncovered more likely is that the cost of treating it will be lower. In the software industry the cost at the early phases can be from 10 to 5 times less the cost of handling a problem when it is too late.
The art/science of managing people on a project environment is one of the most important aspects of project management. The project team quality is as good as the quality of the actions of the individual team members, in the sense that if you have low quality team members you’ll never accomplish a high performance team but if you have it than it’s easier to build a good team (but not guaranteed).
This leads me to the topic of individual motivation and behaviour. The individual behaviour of each team member is crucial for having good team dynamics. A thing that I call work ethics is central to the concept of individual improvement and team building.
I define work ethics as the basic behaviours that you are counting on that each individual will use to help him to produce the results that are expected. I’ll count behaviours like “if you can do it now don’t leave it for later” (proactive), “if you can’t comply warn the appropriate team members”, “ask for clarification whenever you feel you needed”, “if you have something in your mind tell it”…
These behaviours are not trained in schools (at least not in Portugal) and usually only more senior personal is capable of presenting this kind of behaviour consistently.
In this environments the project team but especial the organization must play a key role in shaping and helping to adapt the team members to the organizations work ethics to sustain a good work environment while increasing its efficiency.
What is your opinion? Post your comments.
Want to know what is the relationship between the Sarbanes-Oxley Act of 2002 (SOX) and Earned Value? There is a great article about it at http://www.line56.com/articles/default.asp?articleID=6099&TopicID=3
Now that more and more European companies worry about SOX implementation this should provide a good understanding about the usage of EVM to increase transparency of the organization results.
The aim of this article is to demonstrate that the usage of EVM for small projects is feasible and the benefit provided by EVM largely compensates the effort/cost of applying it when using a practical approach. This paper will describe the usage of EVM in those situations and will finish with a case study.
If the task does exceed several reporting periods than I recommend using an apportioned relationship to other discrete work packages or a combination of percent-complete estimates with milestones used as gates.
So the main question is how to identify potential problems and when to act.
When analyzing the EVM indexes one might acknowledge degradation on the performance of the project or maybe a trend that could lead to a decrease of the performance of the project. But the main question remains: is it time to act? If so what to do?
The model that I use associates activation limits to the EVM indexes. For example if CPI or SPI:
In each review period (usually one week) the indexes at the phase level must be analyzed and eventual problems should be looked at following a couple of rules:
If this deviation is a risk trigger or expected as part of a response to a risk activate the proper response (could be do nothing)
If the deviation is not explained by the identified risks than search for the cause (In small teams this is usually done quite fast due to the reduced number of communication channels therefore lower complexity – analysing CV and SV of the lower level tasks) and identify the risks that could happen due to the identified cause. Next plan for a proper response.
As much as possible during risk identification the risk thresholds should use the EVM indexes to enable association of actions to specific values of the indexes.
To predict future project performance Estimated Cost At Completion was calculated in it’s optimistic form, ECAC Likely and EDAC were also used (If the progress is bigger than 15% otherwise the previsions should be equal to the baseline):
Estimated Cost At Completion Optimistic (ECAC Optimistic): Planned Cost/CPI. This assumes that the resources productivity will be constant.
Estimated Cost At Completion Likely (ECAC Likely): AC+(Total Planned Cost – EV)/(CPIxSPI). If SPI between 0 and 1. This assumes that if a task is late than the productivity will be affected and is equal to CPI x SPI for the remaining work (Planned Cost-EV). Otherwise ECAC Likely=ECAC Optimistic.
To predict future project duration Estimated Duration At Completion (EDAC) as used and is equal to Planned Duration/SPI.
When a task is recovering (a task is recovering when it was supposed to have finished but it is still being executed) EV is going to progress towards PV and PV is always the same causing the progression of SPI towards 1 (the baseline is extending until the task finishes). The following figure illustrates the idea:
The SPI value is expressed in percentage in the right Y axe.
This example illustrates one of the biggest concerns in EVM since SPI in this cases moves way from the real trend of the schedule and if we want to predict future performance based on the classic SPI the predictions will each time be better since SPI is always approaching 1 (that is perfect schedule performance).
In this case we propose that SPI is calculated using the classical way for all the cases except this one. During the recovery period we want to calculate an “Adjusted SPI” that provides a correct prediction therefore: EDAC=Baseline Duration/Adjustedt SPI
Considering that the SPI for a task that is finished is:SPI=Baseline Duration/Actual Duration
In the case of a recovering task our best estimate for the Actual Duration is EDAC and instead of using Baseline Duration we must use (Actual Date-Baseline Start) so SPI does not maintain the same behaviour of approaching 1. Therefore: SPI=(Actual Date-Baseline Start)/EDAC
Replacing EDAC we get: Adjusted SPI=(Baseline Duration/(Actual Date-Baseline Start))*SPI
The next graph compares the evolution of SPI with adjusted SPI.
With the Adjusted SPI we can now calculate with confidence the future project performance and get a clear view of the status of the project. This approach has the advantage of being very easy to calculate using any of the project management software packages or the simplest spreadsheet.