CASoft Blog        CASoft Pty Ltd blog

         Communication Aspects in Software Engineering

March 27, 2010

Earned Value and Tolerance, using critical path

Filed under: Project Management — Tags: — admin @ 09:09

When reporting on earned value, more often than not, the project is slightly behind the original plan and the earned value is below the planned value.
How does the project manager and the project stakeholders know if the variance is within the tolerance of the project or not? What is the bottom-line?…

The project critical path can be used, in order to represent the tolerance threshold, as in the example below.

Values for the chart can be automated using MS Project and MS Excel… See previous post on earned value calculation http://www.casoft.com.au/2009/04/calculate-earned-value-with-tfs.html

For more information contact us – jjacquet AT casoft.com.au

January 17, 2010

Successful Project Management

Filed under: Project Management — Tags: , — admin @ 09:22

One may notice that everyone, in every area of life but more so in project management, claims to be successful and, more often than not, successful only…
How good someone really is, who has never experienced failure, I ask?

We all have strengths and weaknesses, and this means we perform better in some situations than others.

Have you ever noticed that when their is a problem (and there’s always one), most consider self as being outside of the problem, while everybody else considers you as being part of it?

Successful people take ownership of the problem at hand…

July 1, 2009

Agile Project Management with Scrum

Filed under: Agile,Book Review — Tags: , — admin @ 21:04

About Scrum we like the philosophy and the following practices:

  • Feature prioritisation sessions
  • Undisturbed iterations (called Sprints)
  • Functionality presentation sessions
  • Self-organising teams

In a nutshell, SCRUM principles are as follows:

  • All management responsibilities are divided between 3 Scrum roles:
    • The Product Owner focus is focused on Return On Investment (ROI)
    • The Team is responsible for developing functionality. Teams are self-managing, self-organising, cross-functional and they are responsible for figuring out how to turn Product Backlog into an increment of functionality.
    • The Scrum Master fills the position normally occupied by the Project Manager. He is responsible for the Scrum process. Like a sheep-dog, he’s responsible for keeping the flock together (focused) and keeping the wolves away (undistracted).
  • Each Sprint is an iteration of 30 consecutive calendar days
    • A Sprint starts with a planning meeting, where the Product Owner presents the highest priority Product Backlog (4 hours) and the Team plans out the Sprint (another 4 hours).
    • A Sprint finishes with a Sprint review meeting (4 hours), where the team present what was developed. Then the Scrum Master holds a Scrum retrospective meeting with the team.
  • Artefacts:
    • A Product Backlog lists the features with estimates, associated Sprint and remaining work (days) – maintained by the Product Owner
    • A Sprint Backlog lists the tasks, which the team defines for turning the Product Backlog they selected into an increment of functionality, associated with the Originator, the person Responsible, the Status and the hours of work remaining – maintained by the Scrum Master -No Gantt-chart
  • Rules:

For more information, get the book form Ken Schwaber – Agile project Management with Scrum – click on the image below:

June 22, 2009

TFS for Project Management

Filed under: Agile,Project Management — Tags: , , — admin @ 19:31

Team Foundation Server (TFS) is a Microsoft offering for source control, data collection, reporting, and project tracking, and is intended for collaborative software development projects.
It is not just a bug tracking tool.

It is available either as stand-alone software, or as the server side back end platform for Visual Studio Team System (VSTS).

TFS Architecture:


When creating a project, there are 2 project templates to choose from:

  1. MSF Agile:
    • Provide Work items and Processes that support Agile programming approach
  2. MSF CMMI
    • Based on MSF Agile, it stretches the Agile approach to comply with CMMI Maturity level 3.
    • It is 150% larger than MSF Agile, for example MSF Agile has 25 work product artefacts, MSF CMMI has 59.

TFS manages pretty much everything as Work Items:
The recommended links organisation is as follows:

Queries and reports can be developed in order to retreive any data from TFS. There are existing reports, such as Bugs rate and Remaining work.SharePoint Web Access allows web access to all the information in TFS: Work items, Queires, Reports, Documents, Source Control, Builds and also Timesheets. SharePoint can be used by project Stakeholders, including the Customer if you wish.

SharePoint Project Portal provides documents repositories for projects and Wiki features.

The Integration of TFS and Excel allows to extract any data from TFS into Excel, using queries. The data is copied in the spreadsheet and can be refreshed from TFS at the press of a button. The data can also be edited in Excel and be published in TFS. Charts can then be developed in Excel.

It is also possible to develop pivot-table that access the TFS database directly (instead of running a TFS query).

There are also plug-ins to TFS, such as:

  • Calibre VSTS Add-in, which allows synchronisation of requirements with the tool from Borland
  • Test Director Synchronisation Engine, which allows synchronisation of bugs with the Quality Centre.

Also TFS Power Tools, to be downloaded, offer very interesting features, such as:

  • Process Template Editor
  • Work Item Editor
  • Custom check-in policies
  • TFS Server Manager
  • TFS Client Tool
  • Alert Editor

Finally TFS 2010 will offer the following additional features:

  • Architecture Explorer, which is a graphical visualisation of code
  • 7 diagrams UML supported, for design and share diagrams
  • Tools for test cases management, such as tooling for better documentation & test
  • Test Impact View, which allows to run tests impacted by a code change only
  • Enhanced Vision Control, with gated check-in, branch visualisation & build workflow

June 5, 2009

Code Quality – Preventive vs Corrective actions

Filed under: Project Management — Tags: , — admin @ 15:27

When it comes to quality in general and code quality in particular, I very much believe in prevention prior to correction.
When asked about code quality, people tend to offer corrective type solutions. Corrective type solutions are good and necessary, but they are more costly and are worth being minimised by implementing a number of preventive solutions up-stream. Example of preventive actions:

  • Ensure quality of requirements – implement a continous requirements development and recording
  • Ensure quality of architecture and design – implement methodologies for concept and documentation, such as UML and RUP
  • Ensure quality of staff – implement relevant and continuous training programs and recognition programs – manage pressure intelligently
  • Ensure quality of project processes – implement methodologies for project management and software engineering, such as PMBoK, CMMI, RUP and/or a recognised Agile approach.

I have worked for companies which spend a lot of time on the preventive side of things, and other which spend none whatsoever. Experience shows that when time is spent imlementing preventive solutions, the overall time of developing software is no significantly shorter nor longer…
The time normally spent fixing bugs at the end, is instead spent up-front insuring quality. But then dividends pay in the maintenance phase, where things get much easier. One case study demonstrated that 50% less staff were required in the first 5 years of maintaining a software solution re-engineered using proper design and UML approach.
In my point of view, the frequency of total re-engineering needed is also significantly decreased.

As a conclusion, in my experience people implementing Agile approaches often tend to dismiss or minimise the preventive activities in the name of agility, while this is not an Agile requirement and it is undesirable for high quality outcomes.

May 9, 2009

Risk Analysis 101

Filed under: Project Management,RUP — Tags: — admin @ 09:33

In my experience, Risk Analysis is primarily about communication. If the communication going around the project is not open and efficient, no risk analysis approach will save it.
On the other hand, if there is good communication going, a simple risk analysis methodology will do wonders.

The objective of a risk analysis is to identify, quantify and as much as possible mitigate the effects of events that have the potential to prevent a project from reaching its objectives. A risk analysis is not about identifying dysfunctions or people to blame.

The goals of a risk analysis is to:

  • give confidence to the Project Manager that all the contingencies have been considered
  • help working teams to focus on the key issues
  • mitigate the potiential impact of certain risks
  • help to prepare for the unexpected
  • improve the control over the development life-cycle and increase the capability to achieve the project objectives

A common method consists in brainstorming sessions, which allow to establish a list of risks. Each risk has an assignee, who will have the responsibility to help analysing the risk, usually the subject matter expert.
Let’s remind ourselves now one fundamental principle of risk analysis: “No idea is too stupide to be mentionned”. This is why small risks and very important risks will be listed side by side.
Then each risk is the object of a detailled analysis, which will allow to determine the value of a number of attributes. In particular, risks are classified by category.

The following categories may be considered for Software Development projects:

  • Requirements
  • Analysis and Design
  • Coding
  • Test
  • Deployment
  • Training and Documentation
  • Maintenance and Support
  • General

Each risk is also allocated a value for importance. The calculation of the importance is realised by using a Probability-Impact matrix. In the following example the matrix give more importance to the impact over the probability:

 

 

 

 

Probability \ Severity Low Medium High
Low 1 3 5
Medium 2 6 8
High 4 7 9

Still in the context of the calculation of the importance, it is recommended to undertake a ponderation of the severities in relation to cost, quality and planning, in order to take into account the imperatives of the project.

A risk analysis will allow to highlight a number of solutions susceptible to mitigate the risks. Solutions will translate into actions. Some of these actions will need to be undertaken rapidely, in order to prevent the apparition of risks. They are preventive actions. Some will rely on the risk being triggered. They are curative actions.
Each action is allocated a value for importance too, which is calculated with the importance of risks it is mitigating.

Risks may later be managed using Risk Management Plan type document, or project traking type document, such as Status Assessment.

The source of information should also be documented, as context for the risk analysis. For example, list the brainstorming sessions that have happened and the attendees.

When documenting the results of the risk analysis, it is recommended to provide first the catalog of risks as a summary, sorted by importance. Then describe the risks in details by category.
The following attributes are to be documented for each risk:

  • Description – what it is about
  • Indicator – how do we find out
  • Impact (source part, impacted part, probability, impact severity on cost, quality and planning)
  • Possible solutions – refering to actions

The risk repartition may be documented using charts as for example:

  • Severity repartition for planning, quality and/or cost
  • Risks repartition by category (risks number and % importance)
  • Risks control repartition (risks per person, team, group and/or organisation)

Proposed actions are listed with a reference, a description, an undertaking mechanism and associated risks (which are mitigated by the action).

In conclusion, most of the proposed actions should be preventive and therefore undertaken as soon as possible, as a fundamental principle of risks analysis consists in anticipating problems. Indeed risk analysis is not supposed to provide solutions to existing problems, as it is considered to be late.
It is recommended to undertake a process analyse, as per the RUP methodology for example, in order to describe actions in details and to anchor them within a well known methodology.

Finally the risks analysis identifies New risks. The risks management consists in turning risks from New to Open when they are triggered, and turning them from Open to Closed when they have been treated.

Existing problems, at the time of the risks analysis, aren’t identified as risks, since no probability can associated, but they may be managed as open risks during risk management.

April 4, 2009

Calculate Earned Value with TFS

Filed under: Project Management — Tags: — admin @ 20:16

Calculate the Earned Value of a project on a weekly basis, using TFS, MSProject and MSExcel.
In this article we’ll explain how to calculate an Earned Value in days. It can be calculated in $ in a similar way… It is just a little more complicated.
It will work with TFS 2008, Office 2003 and Windows XP.
At the time of writing, it won’t work with Office 2007 and Windows Vista.

1- Define the tasks in TFS

First, the tasks from the work-breakdown-structure are entered in TFS, and assigned to team members as required.
A query will be needed to list all the tasks for your project, including the closed ones, so tasks don’t desappear as they get closed.

2- Use MSProject for the schedule

Though it is possible, it is unlikely that all the tasks of a project will be entered in TFS; typically Project Management or certain tasks performed by Consultants, for example.
Anyway, I like to have a semi-detailed schedule in MSProject, which will cover for all the tasks in the project. The tasks in TFS may be imported in MSProject automatically, using the TFS client tools, but I personally prefer to do this manually.
This is because I might have to prepare a project report as per Friday night on Friday afternoon, and TFS might not always be up-to-date. We have also experienced some problems with this interface.
I do however tend to group TFS tasks into a smaller number of tasks in MSProject, especially when there are hundreds or thousands of tasks, in order to make thinks easier. In this objective, the TFS tasks can be imported automatically in an MSExcel sheet (which works much better), using the query we mentioned earlier.
Then some calculations can be performed, in order to get Remaining time and %Complete values by group of tasks.

3- Export the schedule baseline into MSExcel

For the Earned Value chart, we need the Planned Effort values.
In this objective, we save the schedule baseline using the Resource Usage view in MSProject. Make sure that the values displayed go every 7 days (one week) and then copy and paste them in an MSExcel sheet, and replace the ‘d’ that comes with the numbers by nothing, so they are interpreted as numbers by MSExcel.
Now for each column, we need to add the week number, so it can be reference in the Earned Value table, in order to get the Planned Effort for each week. I personally like to use the format “2009w8″ for the 8th week of 2009 for example.
We also need to calculate the sum of each column and the cumul of the sum for each column.

4- Get TFS Tasks updated

The Developers / Team menbers need to update the tasks that are assigned to them in TFS at least once a week. It is usually convenient to get them to do that at the same time they enter their timesheet. They need to update the Remaining Time and the status of the tasks they’ve been working on.

5- Update the schedule

The list of tasks in MSExcel can now be refreshed automatically with the latest values in TFS, and the schedule can be updated (manually), in order to reflect the progress on the project.

6- Update the Actuals from TFS Timesheet

In theory, TFS Timesheet can update the TFS Tasks Completed Time automatically, but at the time of writting we haven’t been able to get this to work properly.

So in order to obtain the actuals, we’ve been able to setup a pivot-table in MSExcel; Setup an external Data-Source pointing to a view, which is refering to the tfstimesheet table in SQL Server on the TFS Server.

We just needed the Work Item Id on the left, the sum of hours from timesheet entries in the middle and nothing on top, in order to get only one column with hours. Then a SUMIF formula allowed us to update the Completed time in the tasks listed in a different MSExcel sheet and to publish these values back in TFS.

7- Update the Earned Value data from MSProject

The Estimate At Completion (or EAC) for the project will be provided by the value in the Work column in MSProject.

The Earned Value is calculated from the %Complete of the project multiplicated by the baseline budget (in days) or Total Budget in the figure below.

The Total Budget is saved every week, because it can change over time, as the project needs to be re-baselined when significant changes happen. In this case if the history of Total Budget was not saved the values of the Earned Value would be impacted.

8- Draw the Earned Value Chart

See also an approach on how to calculate the tolerance for earned value on this post http://www.casoft.com.au/2010/03/earned-value-and-tolerance-using-critical-path.html

March 29, 2009

Project Take Over

Filed under: Project Management — Tags: — admin @ 11:43

Taking over a new project, a new role or a new job… Restarting.

The objectives a project take over are (in this order):

  1. Ensure long-term success of the Project Manager
  2. Ensure success of the project

In order to take over a project successfully, the following steps shall be undertaken:

  • Establish authority and leadership with confidence
  • Establish relationships with every individual – learn about each one of them, what are their skills, experience, what type of management get the most of them, what are their motivators, personality and character.
  • Assess Project – take ownership of the project plan and the schedule, and assume resposibility from there on – if plan does seem achievable, perform the foolwing actions in this order: 1. try to reduce scope, 2. try technical simplifications, 3. justify and ask for more resources, and 4. propose to replan the project.
  • Assess and document Risks and Issues – perform a complete risk analysis, in order to confirm that the project objectives are achievable
  • Document Vision and Action Plan – based on well know methodology
  • Establish Project Management Master Mind

Spend a fair amount of your time improving your leadership ability:

  • Provide navigation
  • Establish solid ground
  • Influence
  • Process knowledge
  • Get momentum
  • Focus on victory
  • Establish inner cycle
  • Maintain priorities
Older Posts »

Powered by WordPress and Writeup.com.au