CASoft Blog     CASoft Blog

         Communication Aspects in Software Engineering

16 June 2009

Personnal Accountability

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

“I’m holding you accountable for the outcome.”

Lack of Personal Accountability may show through Negativity:

  • Emphasis on blame or deflecting fault
  • Complaining tone
  • Expression of frustration or fear
  • No real productive answer
  • No suggested action
  • Judgemental tone

Positivity, on the other hand, is usually partnered with Personal Accountability:

  • Emphasis on helping or solving the problem
  • Willingness to take positive action
  • No accusation
  • None-judgemental tone
  • Emphasis on being open-minded and taking responsibility

Choose your attitude. Play. Make their day. Be present. Be world class!

15 June 2009

Empower and Motivate Employees

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

Of all the areas of project Management, people have the greatest potential to shorten software schedules across a variaty of projects. In order to be highly successful, Project Managers want to foster a motivating and energizing culture within their teams.
Motivation can make or break projects. It is undoubtedly the single greatest influence on how well people perform. Research studies have demonstrated that motivated Developers can produce up to 10 times more than their unmotivated counterpart.
Many common management practices however are penny-wise and pound foolish, trading huge losses in morale for minor methodology improvements or dubious budget savings.
Although motivation is a soft factor, the knowledge of how to motivate Software Developers is not a total mystery.
For most people, motivation comes through empowerment, autonomy and trust. The major motivation inhibitor on the other hand is fear.

Providing the best environment to promote motivation:

  • Give interesting job and challenging work
  • Provide personal development and flexible policies
  • Eliminate fear
  • Make eye contact and smile
  • Take responsibility – don’t pass the buck
  • Be honest, loyal and work hard
  • Get inside the other person frame of reference
  • Solicit suggestions and act on them
  • Expect people to succeed
  • Be teachable – commit to learning
  • Inspire – touch their heart
  • Handle every single transaction with each and every person, no matter who that person is, as if you will have to live with that person in a small room for the rest of your life

In his book “Rapid Development” Steve McConnel describes the following:

“Compared to their Managers, Developers are somewhat more motivated by possibility for growth, personal life, opportunity for technical supervision. Developers are much less motivated by responsibility, recognition and interpersonal relationships with subordinates.”

Developers and Managers are motivated by different factors, and this may contribute to miscommunication.
In order to motivate a Developer, it is recommended to emphasize technical challenges, autonomy, the chance to learn and use new skills, and career planning.
Let Developers focus on what they like doing most: developing software. Provide opportunities to learn and expand skills. Avoid excessive pressure.
Allow Developers to experience meaning in their work, responsibility for the outcome of their work, and know the actual results of their work activities. Avoid interuptions and distractions. Respect the need for time off.
Developers grow tired of working for unappreciative companies and rewards are therefore important to long-term motivation. Giving certificates of appreciation for example has proved efficient.
Endeavour to catch people doing something right or great, and give them a sincere praise:

I noticed you did [something great] on [that date] .
I appreciated it because [its effect].

Celebrate special events. Provide T-shirts or mugs personalised with the project’s or team’s name.

Proper execution of a performance review can significantly increase or decrease motivation. Take the time to prepare and make sure your performance reviews increase motivation.
Some performance management system are so complicated and bureaucratic however that the simplicity and ease of coaching has gotten lost. Coaching is a simple conversation and one can use the following structure:

  • Opening statement: “I want to talk to you about [general area of performance].”
  • Observation: I’ve observed [behavior].”
  • Impact: “The impact is [impact on the job].”
  • Request: “From now on, I’d like you to [improved behavior].”

Morale Killers:

  • Developers are sensitive to being manipulated by management. They want management to deal with them in a straightforward manner.
  • One of the quickest ways to drop the motivation to zero is to present Developers with an impossible deadline.
  • Lack of appreciation for efforts
  • Inappropriate involvement of technically inept management
  • Not involving Developers in decisions that affect them
  • Productivity barriers and road blocks
  • Low quality and short-cuts
  • Heavy handed motivation campaigns

Finally, competition can get people to stretch themselves beyond what they even thought possible, while having fun. Most people will go a long way to try to win a fair competition.
Encourage team spirit by organising competitions between teams (not individuals). Make sure every team gets to win at some point or another. Recognise the teams for their strength anyway.
Make sure these competitions are about work (no dress or photo competition), and they are about productivity and fun (not just fun and not just productivity).

5 June 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.

9 May 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.

4 April 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

29 March 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

23 March 2009

Project Management Master-Mind

Filed under: Project Management — Tags: , — admin @ 07:20

The Master Mind principle consists in a group of capable and as much as possible complementary people, who cooperate in the spirit of harmony, in order to gain power.
Plans are useless without the power to translate them into action…

The idea behind a Project Management Master Mind is the organisation of a group of professionals dedicated to manage projects, a bit like an informal Project management Office.

A Project Management Master Mind aims at achieving the following objectives:

  • Managing projects to successful completion
  • Sharing knowledge and information – power is ‘organised knowledge’
  • Sharing brainstorming power, decision power and responsibilities
  • Sharing a common vision
  • Providing coherent answers and solutions to project stakeholders – maximising credibility
  • Ability to keep functioning at near full strength, when one member is temporarily missing

The best source to create your Master Mind is within your team.
In your Project Management Master Mind it is recommended to include people with different backgrounds, experience and responsibilities, as for example:

  • Business – such as Business Analyst
  • Technical – Such as Technical Leader / Architect
  • Resource Management – Such as Manager

For the organisation of your Master Mind, you may also want to consider the following:

  • Master Mind members should be located close to each other as much as possible, in order to facilitate the communication as per the points below
  • They should keep each other informed first and systematically – so each member of the Master Mind is credible when standing on his own
  • They should meet often, with regular formal and informal meetings, such as when higher-management or customer is seeking information / answers or decisions need to be made
  • They should seek each other’s agreement for every significant decision – decision that are decided by a group in harmony are more sound and much more difficult to shoot down
  • They should assume full responsibility – The Project management Team is responsible for everything that is going on within the project!
  • They should support and be loyal to each other – discuss any issue or sensitive subject with the person face to face and nobody else, and give empathy

22 March 2009

Maintaining a Shared Vision

Filed under: Project Management — Tags: — admin @ 21:08

Creating a shared vision consists of establishing and actively maintaining agreement and commitment about what is to be done and how it will be done.
A shared vision is a result of an ongoing dialog among all the people working on the project.

The objectives of a shared vision are:
-Facilitating people working together.
-Helping people to attain unity of purpose.
-Creating a common understanding.

Attention: unrealistic proclamations can transform the shared vision into a source of frustration

Define the focus, for example:

The main focus is the success of the project and the customer satisfaction, all along the project life.

Define the Project Structure:

The project structure describes the caps (or roles) and relationships (or interfaces) for a software development project:
-Several caps may be put on one head.
-One cap may be worn by several heads.
-The represented relationships would describe the official communication stream (or process).

Obtain Assignment Acceptance:

People and activities assignments result from an agreement between Project Manager and Assigned person.
When no solution can be found, or for important responsibilities, the acceptance of higher-level management and/or other stakeholders will be required.

Other Areas to be considered:

  • Common Values
  • Team Empowerment and Independence
  • Decision Making
  • Conflict Resolution
  • Proposed Products and Tools
  • Constraints
  • Expectations
« Newer PostsOlder Posts »

Powered by WordPress and Writeup.com.au