Earned Value in brief

Earned Value Analysis in the last years proved itself as one of the best system for project control. It’s importance comes from thefact that we get an integrated vision checking both costs and schedule.

In this article, I will try to introduce the EV concepts. This introduction should help you to apply straight the EV to your project.

Before start with the definition, pleast consider that EV in its correct form would require all the quantities being expressed in term of money. Quite often this is not possible (expecially in large organizations) because such values are not shared with team leaders or because it is difficult to get them. In order to apply the EV concept we just need to substitute the “money” with “person day”. Even if in this way we loose a bit of information related to project indirect costs, the results in term of control are still relevant.

The most important variables in EV analysis are:

  • BCWS (budgeted cost of work scheduled) or PV (planned value)

it represents the initial estimation for one activity. It’s the cost of the activity if it is done as planned. If there are no planned cost, then we used planned days.

  • BCWP  (budgeted cost of work performed) or EV (Earned value)

Continue reading Earned Value in brief

How to organize a new IT team

In this article I’m going to list a number of practical action to consider when we take leadership of a new team or join as manager a new project. I assume planning is one of the most important thing, so I didn’t stress a lot about it. Here I preferred to  emphasize on the “soft” aspects that usually we acquire only with experience.

For the sake of shortness, I wrote the article as a check-list. If needed i will expand the single themes in other articles.

I wrote this list thinking about a team involved in IT work. Nevertheless, I hope that it will be possible to grasp some positive ideas also if the team will be involved in other areas.

Continue reading How to organize a new IT team

In case it happens …

It can happen that an IT manager will be responsible for a maintenance service.

During this activity it may happen that he/she will have to handle emergency situation, that can be caused for example by wrong production releases, problems in test environment, problem in development environment, till in the worst cases production problems.

I’m presenting here a series of actions that may be useful when we need to manage such “nasty” situations.

As first step: try to calm down yourself and the people involved

The worst thing in such cases is to act based on our emotions: there might be an angry costumer and we will try to do everything to set up the situation. In this moments it is important to calm down and do not act based on our impulse, in order to avoid making the situation even worse. Sometimes the best thing is to leave the communication with customers and client to a senior manager or to someone less involved in the problem. If someone working for you is managing the situation, try to calm him/her down and maybe consider that you can handle the communication with the client.

Evaluate the problem in relation to the project and if possible classify it
It may be that who reported the problem didn’t evaluate it correctly or has a dramatic vision of the impact. We should try to obtain the maximum information and to understand the impact of what happened. We need to get rid of all the assumption that people around us are doing and we need to go back to the facts. At this point it will be possible to define the priority of the problem (sometimes it is done automatically) and the causes that originated it.

If needed (and possible) apply a workaround to get the situation to a stable condition.
You will apply this option only when it is needed to get online again an high priority service. If possible so we will apply or suggest workaround that give back the functionality, even if not at 100%. Careful – sometimes a workaround che cause even more damage than the original problem, so before applying it, you should always discuss with the service manager. Just as an example, if the problem was caused by a wrong software change, by using the normal change management tool, is usually possible to get the software (!! but sometimes not the data!!) back to what it was previously.

Continue reading In case it happens …

Financial in a Project

A checklist, good for checking that all cost are planned, when developing the financials of a project plan.

  • Does the financial plan define the expected monthly cash flow as the basis for monitoring the project’s financial performance?
  • Does the financial plan include an appropriate allowance for risks and contingency costs?
  • Does the financial plan base reflect the staffing profile over time and calculate costs at that level (e.g., number of people multiplied by the time they are charged to the project)?
  • Does the financial plan use an appropriate rate for each type of resource (e.g., an assumed average rate, specific rates for known individuals on the project team, or a combination of the two, depending on company policy)?
  • On larger projects, does the costing model include a rate and salary adjustment factor for future years?
  • Does the financial plan document all assumptions with respect to the cost rates along with the other assumptions on which the estimate is based?
  • Has care been taken to avoid adding contingency on top of contingency (i.e., contingency should be provided for only once and managed separately from the activity/task level estimates)?
  • Does the financial plan include other related costs such as overhead, travel, and other expenses?
  • Was consideration given to including a start-up budget allocation to cover the costs of getting the project started such as setting up a facility and hiring or relocating staff?
  • Has everything possible been done to minimize the elapsed time between when the work is performed and when payment is received (where applicable)?
  • Has everything possible been done to obtain progress payments rather than payments based on acceptance of deliverables (where applicable)?
  • Has everything possible been done to avoid holdbacks on milestone payments (a 15 percent holdback payable upon completion means that the project may not make any profit until the holdback is paid)?
  • Where subcontractors are involved, does the financial plan make sure that a subcontractor does not get paid for a deliverable by us until we get paid for that deliverable by the customer?

 

Estimation Checklist

The following is a check list that should help us to understand how much we can trust to our estimation and what is the probability of having later problems.

  • Was a tool or an estimating spreadsheet used in preparing the estimates?
  • Were multiple estimators used to generate independent estimates?
  • Were the estimators experienced in preparing estimates in this kind of situation?
  • Were the estimators experienced in the technology to be used?
  • Was task-based estimating applied to generate bottom-up estimates?
  • Were the estimates compared with rules of thumb and other sanity checks? If yes were they consistent?
  • Did we review the estimation coming from independet sources and did we understand the and rationalize differences?
  • Did we checked the initial assumptions on which the estimations are based?
  • Have the assumptions been validated with the customer?
  • Were the estimates balanced through a process of understanding and rationalizing the major differences between the preliminary estimates (rather than taking the lowest estimate)?
  • Did the estimates assume average productivity rates (rather than maximum), which take into consideration the specific circumstances on this project that will impact upon productivity (e.g., working off-site versus working on our premises)?
  • Was the final estimate the result of a consensus reached on a reasonable, balanced estimate that all concerned could accept?
  • Has the final estimate been reviewed by some one external to the project, which is familiar with productivity and cost data from other similar projects (historical and/or current)?
  • Did we take in account of the activities that often are not considered in tools, as not linked to real development but linked to the project type? Following a list of such activities. Usually part of them is estimated in the project contingency, while other points are estimated specifically (for example change management or quality), however by experience often we do not consider some parts that then lead to an unplanned cost raising and/or to scheduling issues.
    • Interaction with users and clustomers
    • Software Demo
    • Revision of planning, estimation, code …
    • Versioning
    • Tool Installation and Maintenance
    • Preparation and Maintenance of test environment
    • Change management
    • Quality management
    • Explanation of documents
    • Support to other project/subprojects
    • Technical revision
    • Work in tiger team
    • Training on-the-job.

Assessing the status of a project

Following is my list of hints you can use to ensure your projects or the projects you are assigned to lead, are well managed and run:

  • Work plans – does the team operate under work plans that are based on a proven methodology and estimated with a proven estimator? First, is there a detailed work plan showing deliverables, tasks, estimates, assumptions, schedules, and resources you can review? If there is not, this needs to be addressed as a top priority. Projects that try to operate without a detailed work plan run large risks of not meeting client expectations, and ultimately, not delivering on time, on budget, and on scope. Also, as a part of the detailed work plans are the key milestones and dependencies identified, documented, and understood by the team.
  • Time reporting – does the team do weekly time tracking against the aforementioned detailed work plans? Once a detailed work plan is in place, the next step is to actively track work efforts against the work plans. Periodically time tracking against planned tasks and deliverables is a must to ensure the plan is being followed. If time spent is tracking correctly and plans are good, then we will have available metrics such as:
    • the Cost Performance Indicator (CPI), which reports the value of days earned in the planned against days burned (spent),
    • the Schedule Performance Indicator (SPI), which reports the value of scheduled days earned against calendar days burned (spent)

We will see in another article, that if either the CPI and/or the SPI are significantly under, or over, a value of 1.0, then you should be looking into the work plans, the estimates, the skills on the team, scope management, and/or the addition of unplanned tasks to the project. Continue reading Assessing the status of a project

Processes in Software Engineering

To reach high quality levels, when developing and maintaining software it’s needed to develop, maintain and improve processes, as well. Better work processes result in better work products, where  “ better work products ”  means enhanced features, improved quality, less rework, and easier modifications.

Here are the basic principles to follow:

  • Work processes must be designed with the same care used to design work products; work processes must be designed to satisfy process requirements and process constraints, fit the needs of individual projects, and make the work processes efficient and effective.
  • Work processes for each project should be derived from a process framework. A process framework is a generic process model that can be tailored to meet the needs of a variety of situations. The tailoring of a framework involves adding, deleting, and modifying elements to adapt the framework to the needs of particular projects.

Process design and process improvement result in shorter schedules, higher quality, lower costs.

We should however notice that process improvement seldom happens spontaneously: a positive ROI  (return on investment) requires an ongoing investment of time, effort, and resources

It is however important to stress on the second of the points above: processes must be designed and tailored to the specific needs and not taken and adopted from some best practices of other organizations, without an adequate analysis.

Process design is best accomplished by tailoring and adapting well known development process models and process frameworks, just as software design is best accomplished by tailoring and adapting well – known architectural styles and architectural frameworks.

The following general principles applies:

  • There are several well known and widely used software development process models, including Waterfall, Incremental – build, Evolutionary, Agile, and Spiral models.
  • There are various ways to obtain the needed software components; however  different ways of obtaining software components require different mechanism of planning, measurement, and control.
  • The development phases of a software project can be interleaved and iterated in various ways.
  • Iterative development processes: provide the advantages of
    • continuous integration,
    • iterative verification and validation of the evolving product,
    • frequent demonstrations of progress,
    • early detection of defects,
    • early warning of process  problems,
    • systematic incorporation of the inevitable rework that occurs in software development,
    • early delivery of subset capabilities (if desired).
  • Depending on the iterative development process used, the duration of iterations range from one day to one month.
  • Prototyping is a technique for gaining knowledge; it is not a development process.
  • Always remember that mechanisms of planning, measurement, and control used in a software project are strongly influenced by the development process used.
  • SEI, ISO, IEEE, and PMI, provide frameworks, standards, and guidelines relevant to software development process models

Exit Criteria

Every project phase has a beginning and an end.

This means that some criteria will need to be satisfied in order to start a phase and some other will need to be satisfied in order to mark the phase as completed.

Very often we care about the requirement to start (entry criteria), but we do not give enough attention to the requirements that mark the end of a phase (exit criteria), unless they were specified within the contract.

Not being able to respect or not fixing correct exit often causes problems to the later phases or, even worse, if many teams are involved: for example when the development team gives control to the maintenance team it is really important that the documentation respects strong requirements in term of quality, in case not, even the easiest change will imply the analysis of the source code, which can be a really time consuming practice.

Exit criteria do not need to be complex, nevertheless they should include at least the following:

  • Deliverables list
  • Required quality for the deliverables
  • List of deliverables that are going to be produced but not completed
  • List of what is not going to be done and/or completed

There are different ways to define, communicate and monitor exit criteria. What is important is that everthing is prepared at the beginning (ideally during the planning phase), kept as simple as possible and used in project control. Continue reading Exit Criteria

Communication Management Plan

When managing a project, the way formal communication are handled, is quite important.

In this article I’m going to present the characteristics that I believe should be specified when preparing a communication plan, for every document or any other communication media.

These characteristics will then be specified in the “communication matrix” which is usually attached to the communication plan.

  • Scope/Object of communication: In a project there is the need of periodical status report. Maybe it is needed to update on project policies or change management processes. Every formal communication that happen within a project should be regulated and listed in the communication plan.
  • Purpose: For each communication channel (i.e. document or meeting) you list in your plan, you need a brief explanation of the document’s or meeting’s purpose. You want to answer why the communication is needed and under what conditions.
  • Frequency: By writing down the expectations, you ensure that all stakeholders understand how often communication is needed. Defining when milestones are due is essential to the process because you can measure the accuracy of the cost and time baselines to date, and the overall project status.You may also want to set up conditional reporting to establish that when specified conditions are met, individuals should report accordingly.
  • Medium/Channel: It is possible to communicate via report, via e-mail, workflow tools or meeting. What is important is that we specify the format for the communication. Some times it is better a written document, some others a simple e-mail. There’s no right or wrong way to present information, but the preferences and reasons for the modality have to be documented in your plan. For example, you may request that your project team members complete a weekly status report of their assignments in a Microsoft Word form and e-mail it to you. But (and here’s the rub), at each project status meeting the team members should bring the Word document in hard copy so they can use it to verbally review their progress. To save your sanity, you have each team member submit status reports prior to the meeting so you have all the reports at the status meeting. And it’s all documented in your plan.
  • Audience: Every report or meeting will have its own audience. There is no sense in inviting to a meeting people not interested in it, as there is no sense to send a document to someone is not interested in receiving it and in improving it.
  • Duration: Sometimes the communication will happen periodically along the whole project, while in some other cases it could be limited to a period of time or even a single event. In the communication plan we should specify it.
  • Responsibility: One common misunderstanding is that the project manager is responsible for every piece of communication.That’s just nottrue. The project manager is responsible to ensure that communication takes place, but he can’t be responsible for the actual communicating. For example, if an expert is hired to take care of some aspects of the project, it is important that he communicates with the team leaders (and maybe not all). It will be the project manager responsibility to facilitate the communication and to verify that they will happen profitably, but the communications will be responsibility of the team leaders. Sometime it will be important to distinguish between the responsible for the production (e.g. team leaders) and the responsible for the scheduling (e.g. PMO).

 

Critical Chain Method

Critical Chain Method (CCM) concepts where first introduced by a paper written in 1984 by Goldratt (“The Goal” – ed. Gower). The main factor for the success of this ideas is that it finds solutions to the classical problems we encounter once we plan following the Critical Path Method (CPM) approach.

CCPM (critical chain Project Management) is basically a mix of the most recent best practices:

  • PMBOK: Plan & Control.
  • TOC (Theory of Constraints): Removal of bottleneck to solve system constraints.
  • Lean: Remove waste.
  • Six Sigma: Reduce any deviation from optimum solution.

The problems

Going back to CCM, the main problems it aims to solve are:

  • Over estimating

This is a problem that usually comes up when defining plans. In a few words, since:

  • estimation are always cut;
  • details, at the beginning of a project are not always clear;

tasks that have the biggest uncertainty are sistematically over-estimated. We create contingencies, to protect us from the fact that things we don’t know will go wrong. This process is then amplified because estimationa are presented to many stackeholders, at many levels, and often each level put its own contingency so that at the end the project duration (& cost) is usually over estimated.

  • Student Syndrome.

This happens in case of long projects or loose schedules: usually people will start working on a task not when planned but when the delivery time will be near. The reasons are linked both to the other issues we are presenting here (multitasking, parkinson law) and simply psychological: people will not start working till they will not fell the pressure.

  • Parkinson’s Law.

This is a notorious empirical law (Work expands so as to fill the time available for its completion) in Project Management.

In other words if you assign 15 day to accomplish a task that can be done in 10, then it will hardly happen that the work will be completed in 10 day, but macigally it will be completed in 15. Evidences of this law are well known to PMs.

  • Bad MultiTasking

When multitasking is not correctly managed, the result is wasting of time.

This is another well know issue in real projects: when you assign more that one task to a resource, most of the time you will get inefficiencies, because jumping from one to the other, instead of completing one and then the other is only making the most critical task going late.

  • Handling of early finish

The problem in my opinion has even a theoretical reason in the CPM theory. In a few words, even if we would be able to close a task in advance we wouldn’t be able to get the most out of this.

Indeed if the task is not on the critical path, closing it in advance doesn’t give for sure a direct advantage (maybe you get some resources free, but without planning you wouldn’t be able to use them) if on the other side the task is on the critical path, an early closing could not be so relevant (in the sens that we could have other tasks that become critical) and, taking the concept to the limit, we could need of replanning the project or part of it, finding maybe another critical path…

In any case CPM doesn’t give a natural way to handle early close in the project tasks, since it doesn’t plan it.

Continue reading Critical Chain Method