Project Management. Planning Phase. Costs.

In this post I will speak only about several costs’ calculations that can help us to track project expenses. I would like to put all calculation in one table and then make some comments to presented data. Also, I would dwell only on labour calculations, but it would be rather easy to expand them to any project costs.

Parameter

26.02.2013

26.03.2013

Description

PV (Planned Value) – hours 4 000 4 000 Amount of hours we planned for the project.
EV (Earned Value) – hours 480 960 Calculates as PV * %Completed Work. In the example – on Feb 26 we have done 12% and on March 26 – 24% from total amount of work.
AC (Actual Costs) – hours 440 900 Amount of real hours we spent till the moment.

Costs

26.02.2013 26.03.2013  
PV (Planned Value) – $ 40 000 40 000 Costs – multiplication of hours from the previous section on hours cost. To simplify calculations – I’ve taken the value $10. These labor calculations are rather useful as can be used without additional efforts in project reports.
EV (Earned Value) – $ 4 800 9 600
AC (Actual Costs) – $ 4 400 9 000
EVM Earned Value Management 26.02.2013 26.03.2013  
CV (Cost Variance) – hours 40 60 EV – AC

Shows us whether we are in budget or not. When this number is negative, that means we have spent more than has been planned. In the described case – we make some savings.

SV (Schedule Variance) – hours -3 520 -3 040 EV – PV

How many work we still have to do.

CPI (Cost Performance Index) 109% 107% EV / AC %

Is linked to CV coefficient but gives us an opportunity to make an absolute analysis of budget savings or losses. You can see that 60 is larger then 40, but in percents we are losing positions as from 109% we moved to 107%.

 

The main idea of the described coefficients is to signal to project manager on the very early project state, that we have some cost issues and project can miss budget targets. When CV parameter is below 0 and CPI – below 100%, it’s time to intervene and make some corrections in project management. Also, it’s usually very useful to build a chart, showing the changes of CPI.

TFS0027.1

Posted in Project Management, Software Development, Technology | Tagged , , , | 1 Comment

Project Management. Planning Phase. Schedule.

Project schedule – after creation it is used regularly till end of the project. The main schedule I prefer to track in Microsoft Project. In my practice I’m trying to use the following principles while dealing with MS Project:

  • Human resources load can not be more then 80%. On the one hand nobody can work 100% a day, on the other hand there is a small time reserve – it sometimes can help you meet deadlines.
  • All milestones and deadlines from A3 and business project request as well as key dates from risks list must be moved to MS Project as deadlines or other highlighted elements. E.g. I usually marked tasks on which critical risks depend with special colours. I can say that last versions of MS Project provide a vast variety of different design tools, so only your imagination can restrict you ))).
  • I also group tasks by development phases: design section, development section, test section and stabilization section. This helps to estimate the total amount of work for each phase of program life cycle and set logical links between each phase.
  • I try to compose tasks using the following rule: minimum task length 1 hour, maximum – 40 hours. It’s quite hard to register and analyse tasks smaller than 1 hour – such micromanagement would overload project manager. And it’s impossible to track huge tasks – you would never know exactly when the task would be ready – you can face the situation when developer has spent all 100 hours and is still at the beginning of the process. And it’s better to know about the fact we have some problems after 16 hours, then after 100 hours.

The MS Project file can look like:

TFS0026.1

But how we can communicate this plan to project sponsor and business representatives? It’s a bad idea to send them plan in MS Project – they do not need such detailed specification. For this purpose I create a separate file in MS Excel and update it on weekly or monthly basis (depends on the project duration).

This file uses also Gantt principles but much simpler than MS Project:

TFS0026.2

The vertical red line shows current week. This file is a top level schedule for the project and is rather suitable to be presented to project team.

Posted in Project Management, Software Development, Technology | Tagged , , , , | Leave a comment

Project Management. Planning Phase. Communication Plan.

Communication plan is a set of matrixes and procedures to regulate relations inside project team and with outside teams and individuals. Usually I do not publish communication plan as a separate document, it’s the part of Project Management plan.

In my post I will go through main section of communication plan, briefly describing each of them.

Responsibility Assignment Matrix

Name \ Phase Request Initiation Detailed Planning Execution & Control Closeout
Name 1 A P R    
Name 2       I S
         

Letters have the following meaning:

  • А – accountable for the project phase,
  • P – participant in the project phase,
  • R – review required,
  • I – input required,
  • S – sign-off required.

Distributed structure of information flow

Name \ Document Status Report Data Schedule Technical documentation Test Plan
Name 1 W        
Name 2   M      
         

In this matrix we list all milestone documents of the project and how we’re going to communicate them to the team. W – means written communication, M – means meeting communication.

Generally for small and middle projects these two matrixes are enough. But for complex, large and formal projects I’d suggest to add some additional information to communication plan:

  • Provide a description of the information to be distributed, including format, content, level of detail, and conventions/definitions to be used.
  • Develop schedules showing when each type of communication will be produced.
  • Describe methods for accessing information between scheduled communications.
  • Determine when and how project communication plan should be updated. For not large projects it’s updated on monthly basis as a part of Project Management plan.
Posted in Project Management, Software Development, Technology | Tagged , , , | Leave a comment

Project Management: Planning Phase. Functional & Technical Designs.

I would like to start detailed description for the Project Planning Phase with Functional and Technical designs. As I’m speaking about software development projects, this post will have some specific, and of course you cannot use the same templates for example building projects ))).

Another important thing is that designs are normally does not created by Project Manager – we have determined analysts on Initiation phase and design development would be their task. Usually analyst on business side (business itself or product manager in the project team) develops functional specification and technical architect or technical lead is responsible for technical design.

Based on my practice I recommend starting design development ASAP. The main reason is that these documents are the most complex and large among all other documentation created during Planning Phase. It’s usually takes a lot of time to create them, also we need some time for approving them. Also these documents are base for other activities:

  • You cannot start detailed project planning without full list of tasks with baseline hours. And this list can be created only when technical design is completed.
  • You cannot determine the project team, as you do not know what technologies are planning to be used during the project, so you do not know what kind of specialist you are required. This information is also contained in technical design.
  • And you cannot start real work on technical design while not all user requirements are collected. This work is done while functional specification development.
  • Of course costs and risks are also closely linked with these documents.

To sum up, if you do not want to have real bottle neck and pauses during the detailed planning phase, start developing of this documents even on Initiation phase, do not delay this work and try to involve analysts on 100% into project on Planning Phase.

The quality of these documents is another important thing I have to say about. If you have made a mistake in the architecture and this was noticed during design agreement, it would take rather small amount of time to put some changes into the document. But imagine, what would happen if this error is identified on users test stage. I have an example when such error has caused loss of 800 hours of developers’ work and restart of the project. As a conclusion, be mindful of the time, but do not forget about the quality of the functional and technical documentation. They are the baseline for your future development.

At last let’s briefly describe each section of functional and technical designs with some comments.

Functional design

  • Introduction – this section contains context, scope, definitions, references, etc.
  • Process overview or functional model – the main section which usually varies for each project and contains requirements, process description, etc.

Technical design

  • Logical model – this section contains logical database models, users’ forms, not very technical description of the logic developer has to implement. Business or functional analyst must understand this section. Usually I try to approve it with project leads on business/customer side.
  • Physical model – this section is for developer only. Physical database structures, internal algorithms (architecture of storage registers or encryption algorithms), etc.
  • Security – this section is dedicated to user permissions for developed functionality. What new application roles must be created, who would have access to fields and buttons and who wouldn’t. Usually this section translates requirements from functional design to developers’ language, so there is no need for additional approves with customers.
  • Interfaces – this section contains description for data interfaces between informational systems. It’s usually for matching of tables/fields in one system with tables/fields in another – rather technical, for internal use only.
  • Data Edits – in this section massive one-time data uploads from external sources are described. Also for internal use.

So, that’s all I wanted to discuss about functional & technical specifications development. In the next post I would continue writing about Project Detailed Phase.

Posted in Uncategorized | Leave a comment

Project Management: Planning Phase (Brief Description).

So, we’ve come to the most important phase for Project Manager – Planning Phase. Why is it so important? The main reason is that on this phase we lay the baseline for the whole project. And with poor foundation any “building” would crash. This building – is our project, and its success depends on how we pass through Planning Phase.

The purpose of Planning Phase is to sign off key project document – Project Management Plan. I will for sure describe it in details in my future posts.

Below I will list documents/activities that must be done during this phase, and all of them are on final stage combined into Project Management plan. So, let’s start:

  • Application Design (Functional and Technical if required) – detailed description of new application and identified solution for customer and for IT. The document must be published and approved before any development has started.
  • Project Schedule – major milestones, tasks with time frames, resources accountable for tasks, critical path, deliverables and due dates. I prefer to have main plan in MS Project for everyday work and high-level plan in Excel for monthly updates to customers.
  • Costs – people time, hardware and software required for the project.
  • Risk Assessments – I’ve described this part in one of my previous posts Project Risk Management In TFS.
  • Communication plan.
  • Project Management plan.

After all activities are performed we’re moving to Execution & Control phase, but can return to the Planning phase again. This happens when project face ensure impact of any change in scope, schedule, architecture, capacity, value being delivered, etc. But in spite of this change project can still produce desired business result and value. In this case it is required to obtain agreement that a proposed change is needed and will still deliver required business value. The special Change Document is prepared in this case, to fix changes in the project.

Also, it is important to say, that from Planning Phase project manager usually starts regular Project Progress Reporting. Progress reporting should be at least monthly, but during active periods of the project (when we deal with business, start testing, prepare for go-life) I do it weekly. During one of my projects I sent reports even on daily basis – this was during final test iteration and it was important for business to monitor the amount of open issues and dynamics of issues closing.

From the next post I will step-by-step describe in details all documents mentioned above with examples from my project management experience.

Posted in Project Management, Software Development, Technology | Tagged , | 1 Comment

Project Management: Initiation phase (part 2)

In this post I will finish the story started a week ago about Project Initiation phase. We have determined high level objectives and scope of the project, put down boundaries and constraints and check whether our activity is a project or just a work request.

Now we have to prepare for detailed planning phase.

Team Roles for Planning

First of all you have to perform some planning activities for Detailed Planning phase of the project. And two next sections are about it.

Initial step is to determine the responsibilities of team members for planning phase. The points can be the following:

  • Project Lead from business (name) – organize work of working team on business side. Main contact for IT side.
  • IT project manager (name) – project planning, preparation and approve of all needed project documentation, project weekly track, organize regularly project meetings.
  • IT analytics (names) – develop and provide sign off functional and technical designs for the project.
  • Project working team on business side – consultations, approvals of some project documents.

Detailed Resource Utilization for Planning

This is the continuation of the previous section. But here I put down some timeframes and % utilization for project team members.

  • IT project manager (name) – Dec 2012 – Feb 2013, 20% utilization.
  • IT analytic 1 (name) – Dec 2012 – Feb 2013, 50% utilization.
  • IT analytic 2 (name) – Dec 2012 – Feb 2013, 25% utilization.

Signoffs Required before Detailed Planning Tollgate

In this section I determine what documents and by whom must be signoff before detailed planning phase tollgate. E.g.:

  • Project plan signoff: IT Director, Project Lead from business.
  • Functional designs signoff: Project Lead from business, Names from working team on business side.
  • Technical designs signoff: IT project manager.

Detailed Planning Phase Tollgate Participants

Here I set some dates and attendees for Detailed Planning Phase tollgate. It can look like:

  • Approximate date of meeting
  • Mandatory attendees.
  • Optional attendees.
  • Who signs off on the gate

Next Steps

Just very high-level plan of what activities we are planning to do during the project planning phase:

  • Develop functional designs for SYSTEM1 and SYSTEM2.
  • Develop technical designs for SYSTEM1 and SYSTEM2.
  • Risk Management.
  • Develop Project Management Plan.
  • Determine project team for Execution and Control phase.

This is all about Project Initiation Phase. Of course two posts were high level, but I try to make them more specific filling it with real-life examples. The next series of posts will be about Project Planning phase.

Posted in Project Management, Technology | Tagged , , | 1 Comment

Project Management: Initiation phase (part 1)

In the Project Management Request I’ve concentrated on the request pre-phase of the project and on its main document A3. If A3 has been approved by project sponsor it’s time to start project initiation phase.

Initiation phase precedes Project Detailed phase and prepare Project manager and project team for real work. In this post I will try to list all activities that better to perform and document during this phase. The output of this phase is Project Kick Off Meeting where described below information usually put into slides and presented to the team.

High Level Objectives

In this section I summarize in several points what the project is about and what results are needed to be achieved. Example from one of my projects:

  • Develop system for metallurgical waste management in Cast House workshop.
  • Create in the ERP system charge reception block.
  • Automate charge reception and outgo with barcode scanners and production scales.

Scope

This section I use to detail project team and what regions and systems project would affect. E.g.:

  • Organization structure
    • Project Sponsor
    • Project Lead from business
    • IT project manager
    • Project working team on business side
  • Technical structure:
    • The project would affect CH and FRP business units only on <PLANT NAME>.
    • The new functionality would be developed in <SYSTEM1> and <SYSTEM2>.
    • Some functionality from <SYSTEM3> will be transfers to other systems and data will be sent to <SYSTEM3> through internal interfaces.

Boundaries / Constraints

This section is rather important and must be worked out in details as soon as possible. Based on this section I set most of deadlines in Project Plan, also it’s a foundation for risk management. And if you miss anything here, with a high degree of probability the project would be unsuccessful. Also project team, project sponsor and everybody who deals with project must have the same understanding of boundaries and constraints of the project, so this section must discussed and approved if needed.

What points can be listed here:

  • The first phase of the project must be implemented into production environment till 31 July 2013 and the whole project must be closed till the end of 2013.
  • All new functionality of the project must be created in the existing systems (SYSTEM1 and SYSTEM2).
  • The project will be performed by company internal resources, no independent contractors are allowed.
  • The agreed scope of the project cannot be reduced.

Project Sizing

For this section I fill special survey to check whether this activity is a project or just a work request. For projects it’s preferable that you follow all steps of project methodology. While for work requests you can miss some steps as the activity is not so complex to perform full management.

The survey contains simple calculations and if you reach required amount of points – the activity is set to be a project. The sections of the survey are:

CRITERIA

WORK REQUEST

PROJECT

WEIGHT

Project Cost; resource costs including consulting. 

<= $10K

> $10K

5

Project Duration

< 7 months

7 months or more

4

Project team

<= 10

>10

4

Project manager dedication (per cent time)

<= 50%

> 50%

3

Well-documented, operational or maintenance processes used

Only existing, well-documented processes are to be used

Several new process are needed to be developed or modified

4

Team experience (in technologies / subject area needed for the project)

Trained and Experienced

Lacking some training / experience

4

Clarity of scope

Clearly defined

Undefined, vague scope

4

End User Buy-in (buy in of those who will use the result of the project)

End user acceptance a given

End user acceptance needs to be sold

2

Organizational Impact

Impact 1-2 business units

Impacts more that 2 business units.

2

Deadline and cost

Schedule and costs is flexible (+/- 1 month, +/- 20% on cost)

Deadline is fixed and cannot be changed, schedule has no room for flexibility

2

Technology

Proven, existing technology with in-house expertise

Unproven, new technology that we don’t have or proven technology but not in house or not proven but in house expertise

5

Change to current work environment, tools and/or process

Minimal change

New technology and/or new process

3

Number of systems to be newly integrated (may apply to applications mostly)

0-2

> 2

2

Number of external project dependencies

No major dependencies or inter-related projects; or only low risk dependencies to other project

Major high-risk dependencies or inter-related projects
or
Some dependencies or inter-related projects that are not considered low risk

2

Level of complexity (number of technologies, existing applications ala GAR, integrations, etc.)

Simple

Medium – High level of complexity

2

Number of Suppliers

0-2

> 2

3

Confidence in Supplier

High
standard, agreed Alcoa / supplier process that is reliable
or
there are no suppliers involved in the work

Medium-Low
new process with Supplier, or no agreement yet made

3

This is all for today, it the next post I will finish the high-level description of Project Initiation phase.

Posted in Project Management, Software Development, Technology | Tagged , | Leave a comment

Project Management: Request

From this post I would like to switch from TFS reporting to Project Management. The main reason is, that I have described all reports my team is using in everyday work. But of course, if we get some new ones – I will post about them for sure.

So, what are the phases of a project? Let’s see them on a chart:

TFS0020.1

I will go through all phases in my future posts but today I will speak only about Request phase. This is a step before project stats. Its main and usually only document is A3. A3 is a story written on a single sheet.

TFS0020.2

Let’s briefly explain each section of the document:

  • Business Case:
    • Background – explains the context of the problem or improvement
    • Business Need – derived from or linked to the Business Plan and / or higher level A3.
    • Problem – specific opportunity or problem to be overcome including performance measures.
    • Current Condition:
      • Actual current state (as opposed to perceived state).
      • Identification of key issues of waste and opportunities for improvement (linked to business case).
    • Target Condition:
      • Description of the target condition.
      • Reasons why achieving target condition will address the improvement opportunity or solve the business case problem – explanation of any assumptions.
    • Action Plan:
      • List а what must be done and how (with due dates and responsible persons).

The A3 document must be necessarily approved by Project Sponsor, only then we can initialize project start. Also project team must always return to this document checking whether we’re going in right direction.

To sum up, I’m posting the example of an A3 from one of my projects:

TFS0020.3

Posted in Project Management, Software Development, Technology | Tagged , , | 1 Comment

Project Risk Management in TFS

In this post I would like to continue speaking about how TFS helps me to path through project detailed planning phase. Initiate discussion can be found at Projects Detailed Planning Phase. Why TFS?.

This time I will speak about Risk work item and how we use it in Project Management. Generally, this post will be dedicated to Project Management rather then TFS.

The purpose of the Project Risk Management is to identify, analyze, and respond to project risks in order to maximize the results of positive events and minimize the consequences of adverse events. The Risk Management process ensures that each risk identified within the project environment is documented, prioritized and mitigated wherever possible. The Risk Management process is fundamental to the successful delivery of the project.

So, standard Risk work item looks like the following:

TFS0019.1Let’s go through fields of this work item:

  • Title – I’ve got a list of risk titles which are grouped into three categories (client environment, team environment and system complexity). They cover different aspects of risks sources and I use this list as a template to create a list of not filled with other information risks at the start of the project.
  • Area, Iteration – standard TFS fields. In my case they help me to link to application and iteration of the project.
  • Probability – a percentage indicating the estimated likelihood that the risk will occur. I usually use values 5, 20, 40, 60, 80.
  • Assigned to – a person who is responsible for risk response.
  • Blocked – we do not use this field.
  • Priority – the priority of the risk. Can be 1, 2, 3 (the highest).
  • Severity – determines which risks should have a response plan. In our case this values are Critical (for sure) and High (recommended). This field is usually calculated using Probability and Priority fields:
Probability\Priority 1 2 3
5% Low Low Medium
20% Low Medium Medium
40% Low Medium High
60% Medium High Critical
80% High Critical Critical
  • State – contains the following values: Proposed, Active, Resolved, Closed. I keep risks on Proposed status, put it on Active state when risk occurs and send it on Resolved  when we solved it or to Closed when the risk is cancelled.
  • Description – what could happen or go wrong? The main core of the risk.

TFS0019.2

  • Mitigation – is filled usually for Critical and High risks and contains instructions how to reduce the probability or consequences of a risk event to an acceptable threshold reducing the expected monetary value of a risk event by reducing the probability of occurrence, reducing the risk event value, or both. They accomplish this via many different means that are specific to the project and the risk. Mitigation steps, although costly and time-consuming, may still be preferable to going forward with the unmitigated risk.
  • Triggers – for each risk, we are identifying the triggers or symptoms, to help provide early evidence that the risk is about to occur, or is occurring and define which strategy will be applied to respond to the risk event.

TFS0019.3

  • Contingency Plan – is developed usually for Critical risks and contains the list of actions needed to reduce the likelihood or consequences of impact to the project’s objectives. These plans describe the course of action to take should the risk trigger or symptom occur. Determine the response based on a cost/benefit analysis (cost vs. expected effectiveness);
    • Describe the actions to be taken to mitigate the risk;
    • Describe the actions to be taken when the risk event occurs (determines which risks should have a contingency plan);
    • Assign responsibilities for each agreed upon response;
    • Assigned a “due date” where risk responses are time sensitive;

Also we have standard fields that have every work item:

  • History tab – contains the list of all changes that were made to the risk.
  • Links – links to some documentations, folders, sites.
  • Attachments – some additional attachments that can be linked to the risk.

These three tabs are really great, as they give us an advantage over Excel. Excel cannot provide us with these functions and my practice proves that these tabs are very useful.

That’s all I’d like to tell about Project Risk Management and how TFS can help us doing it.

Posted in Project Management, Technology, TFS | Tagged , , | 1 Comment

Baseline vs Completed

Today I will describe one more report we’ve created in order to analyze how baseline hours refers to the actual time spent on the solution of the task. This information is rather useful. Baseline hours in our team are planned by a single manager and he does not know who will deal with each task. So, we have quite good point to compare members of the team.

First, let’s mention some metrics we’re operating in our everyday work:

  • Every developer has to close at least 7 hours each working day. This is controlling by daily management process and we have made it work.
  • The minimum number of hours developer closes a week is 35.
  • The minimum number of hours developer closes a month is 145.

While analyzing development time, we have to exclude hours spent on vacations, internal researches, meetings, etc – all activities that do not change code. In our case – that were not moved to the production environment.

In other words, it will be great to calculate how many baseline hours were moved to the production and how many actual hours were spent by each developer to achieve it.

For this purpose, the Baseline vs Completed report was created. Its main principles are the following:

  • Only implemented into production tasks are analyzed (how to find such task was posted in Deployment tab),
  • We analyze year period – in order to reduce the influence of vacations and time spent working under projects (when for several months the functionality is developed and tested – no deployments to production).
  • It was decided, that monthly average amount of baseline hours transferred to production must be more than 40. So, if developer has performance index more than 28% – we consider, that this is ok. We may be rethink this number in the nearest future, but today it’s 28%.

The first part of the report shows general pivot with average hours for the year.

TFS0018.1

While analyzing this report we can see:

  • Those who is working rather poor. They are located in the red area.
  • Those who spends much more time on the task than was planned. For example: developer monthly average baseline hours closed for the year is 91, but actually he has spent 142 hours to achieve such result. Basically this means, that developer remains after work to complete tasks in time.
  • Those who are doing much faster (baseline 146 only for 87 actual hours). Usually we have quality issues with fast done work.

The next part of the report shows average hours on a monthly basis:

TFS0018.2

This detailed report gives us possibility to go down to the lower level for further analysis. It’s quite simple and has the same principles as first pivot.

In our team we are looking at this report on monthly meetings where we discuss how we did in the last month. And usually we spend 5-6 minutes discussing its results and looking forward to correct “red developers”.

Posted in Software Development, Technology, TFS | Tagged , , , , | Leave a comment