Friday, March 22, 2013

"To improve is to change, to be perfect is to change often"

The current business environment is very volatile, things are always changing. Companies need to be able to change quickly in order to keep up with the market, or even better, in order to drive the market.

Winston Churchill said "To improve is to change, to be perfect is to change often". Another interesting quote about change comes from Charles Darwin, he said "It it snot the strongest of the species that survive, not the most intelligent, but the one most responsive to change".

Organisational change management is something that not many professionals, including senior executives, know how to deal with it. I have encountered one too many executives that think that training is all there is to change management.

Wikipedia defines change management as an approach to shift organisations or individuals from a current state to a future desired state. It is an organisational process aimed at helping members of the organisation to embrace, or even desire, change in their business environment.

Change management uses structures and tools to control an organisational change effort. The goal is to maximise benefit and to minimise impact on workers to avoid distractions.

Responsibility for change management lies with executives and managers. They are responsible for introducing change that brings about improvement in a way that employees can cope with.

One classic mistake in change management occurs when managers spend months working on a change process and then expect everyone to accept it. Change needs to be gradual but constant.

John Kotter is a well regarded author of change management books. He recommmends the followwing steps for successful change.
  •  Increase urgency. Explain and lead others into accepting and desiring the change.
  • Build the guiding team. Gert the right people with time, commitment and the necessary skills to achieve the desired future state.
  • Get the vision right.
  • Communicate for buy in. Communicate the change often with the objective to get buy in. You want people to desire the change and see it as positive to their circumstances. Make communication simple and straight to the point. Although communication is important, getting the balance right is vital so you will not be overbearing and bore everyone to the point they don't want to hear about it.
  • Empowerment actions. Senior management must empower  change agents into action, remove obstacles and do all they can to  support the process.
  • Create short term wins. Gradual change is ideal and easier to process. Constant and positive change minimises the impact on the organisation and keeps the moment going.
  • Don't let up. Long change process can be hard to achieve. Keep everyone motivated and working towards achieving the next milestone. Gradual change that can be achieve in bite-size chunks will keep everyone motivated and moving towards the final objective.
  • Make change last. Make change part of company culture, employ workers that embrace change and always want to achieve new heights.
Business change is not only necessary but it is vital for businesses to survive in volatile business environments.

Sunday, March 17, 2013

How to loose your job by being a good manager

If you have done any formal eduction in management and leadership you will know that these terms are different and have profound practical differences.

Let me give you an example. I once worked for an IT manager who was a very good manager. His planning skills were great, fantastic attention to detail, he was organised, he was able to get the team organised and he controlled the activities quite well, ensuring that deadlines were met and the department operated within the budget constraints. These are the basic functions from a manager, planning, organising and controlling.

This manager was always prepared for his meetings and he was very proud of being logical and getting people on his side using his critical thinking and argumentative skills. However what he didn't realised that he didn't win every argument because people agreed with him, instead, he was always right because nobody could argue him out of his views, even if they didn't agree. He was actually very good at presenting his views and getting others to "agree" with him.

I must confess that I thought that working under him was great. The team was producing good outcomes and delivering projects on time and within budget.

However something was happening in the background. Other mangers and directors were getting resented of

Tuesday, February 26, 2013

Project management tools for Agile projects

This is a post by guest blogger Steward Copper

A few days ago I was attending the IT Project Management Conference and participated in a survey. All the attendants were asked one question: "What project management tool or solution do you use for the Agile projects?" Among the Top-10 Agile tools there were the ones I'd used to manage, plan and track my projects and processes - MS Excel, Pivotal Tracker, Comindware and VersionOne. So, let me share my thoughts and experience of using them for task management, sprint and iteration planning, daily meetings, burn-downcharts creation, project tracking and other Agile techniques.

MS Excel

The tool is a standard part of the MS Office package. The main general advantage of choosing it for your next project is that almost everybody is familiar with it and you don't need to spend time for the team training. It's used by many Agile PMs because it:

 - allows to create a product backlog while listing user stories, placing estimates and deadlines;

 - allows to plan iterations or sprints (it's good to create a template on a specific sheet);

 - allows to group tasks into sprints using a using a standard group tool;

 - allows to add any kind of comments for the tasks, stories and other entities using a standard commenting tool;

- allows to support daily stand-ups while filling a sprint progress data;

- provides very high level of flexibility while drawing graphs including burn-down chart, creating custom reports including digital dashboards and so on.

Excel helps many of us to manage projects but it's not so good for remote teams and big projects. Some managers don't use Excel because it doesn't provide the set of predefined processes.

Pivotal Tracker

The tool was created as a SaaS issue tracking system and evolved into a complex solution to support all the main processes of an Agile project. It's chosen thanks to the following:

- it's developed especially for Agile projects and uses Iterative Management Workflow approach;

- it allows to create iterations or sprints including tasks (tickets) of different priority;

Tuesday, February 12, 2013

How to develop effective professional relationships

We all know how important it is to build effective professional relationships. Relationship management is a very important skill for every professional that wants to get ahead. This article will focus on how effective relationship management helps the CIO to get ahead.

The top IT job is very complex and demanding, effective relationship management enables the CIO to build rapport with his/her peers and will most certainly make the job of managing IT much easier.

Before proceeding, it is important to define what the term "effective professional relationships" means. The CIO should spend most of his time interacting with his peers in order to understand the organization's needs and provide adequate IT solutions. Furthermore, the CIO needs to be able to convince other members of the organization that a particular IT project will deliver positive outcomes to the business. Effective relationship management are the ones that enable the CIO to effectively interactive with every member of the organization in order to enable him to achieve his objectives.

The following points provide useful insights on how to develop effective professional relationships.

Know your company and the people you work with


This should go without saying, but it is really important that CIOs know their business. What I find interesting about IT management is how broad the role really is. As an example, a Supply Chain Manager is required to know all about supply chain.He is not meant to know anything about how to operate the email server. However, the IT Manager, the one who wants to do a good job, is required to know not only about IT but also about every other area of the business. Obviously the IT manager is not required to know everything  in detail, however he needs to know enough about every area of the business in order to have systems in place that support the various business processes. I find this quite interesting and is what makes the job so interesting.

Monday, February 4, 2013

The Good Product Manager vs. The Bad Product Manager

Today I came across the Good Product Manager/Bad Product Manager courtesy lecture at the Stanford university by Ben Horowitz, I believe this post is a classic for product management.

I have summarized Ben's points as follows:


 Bad Product Manager

  • Always makes lots of excuses.
  • A bad product manager is not the product's CEO.
  • Lacks in communication skills. Bad product managers don't communicate well with the engineering team and tend to blame them when things go wrong due to bad communication.
  • Puts out fires all day and complains that is swamped by questions and interruptions.
  • When things go wrong they quickly point out that they predicted they would fail and the "powers of be" didn't do anything about it.
  • Bad product managers focus the team on the feature that the competition is building.
  • Bad product managers get confused on how to position their products on the market and how to leverage it.
  • Bad product managers don't know how to work with the press, they don't manage the press.
  • Bad product managers always want to be told what to do.
  • Bad product managers don't produce status reports on time and are not disciplined.
  • Bad product managers don't take responsibility and tend to blame others.

Good Product Manager

Tuesday, January 22, 2013

Effort Estimation in Agile Software Development - Applying the Pert Weighted Average formula - Part 2

Back in May 2010, I posted an article entitled Effort Estimation in Agile Software Development - Applying the Pert Weighted Average formula, which has been one of the most popular articles on this blog.

Amongst the feedback received there were many requests asking me to provide more details on how to devise the numbers to apply on the formula. This article expands on the topic by explaining my way of coming up with the numbers for the optimistic, pessimistic and realistic components of the Pert Weighted Average formula.

As explained here, the I use the following formula to estimate the duration to develop each user story that make up an iteration: (Optimistic + (4 * Realistic) + Pessimistic) / 6 .

How to apply the formula

Tuesday, January 15, 2013

What makes a good software developer?

Today at work I started to do some performance reviews. As I prepared the review papers  I started thinking about what makes me rate one developer higher than another.

So the question really is, what makes a good software developer? There are certainly many answers to this question and viewpoints will vary greatly. I don't think there is a definitive answer as the definition of "good" will change depending o what you are trying to achieve.

The following sections provide a high level summary of my thoughts on this very interesting topic.

Technical Skills

Technical skills are definitely very important, however I think that it is overrated. Attitude is far more important than technical skills. More on that later.

Possessing well developed technical skills enables developers to complete their tasks faster and therefore it has the potential to make them more efficient. In the past 2 or 3 years I have introduced new technologies in my current organization. Those projects didn't come without challenges, there were some rough days and times of low productivity. The developers with more advanced technical skills were able to understand those technologies and become more productive faster than the others. The real good developers became mentors to the other ones, without making them feel bad.