"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.

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
his approach and attitude. He was always right and never prepared to give up on his views, even when most people had differing opinions. To cut a long story short, he is a now a very happy man who got a very big redundancy package and, given his age, has retired.

He had very good management skills but very poor leadership and people management skills. His strong management skills, and lack of leadership, git him to a redundancy.

So what went wrong. I observed the entire thing trying to learn what to do and what not to do. Working under him I learned a lot about management and also learned a lot how not to deal with people.

Management skills are very important and managers need to be strong when necessary. However people need to be truly on the manager's side rather than compelled to do what he says just because he is always right.

So what are the differences between management and leadership? I have come across many articles that explain the difference. In his 1989 book “On Becoming a Leader,” Warren Bennis composed a list of the differences, as follows:

– The manager administers; the leader innovates.
– The manager is a copy; the leader is an original.
– The manager maintains; the leader develops.
– The manager focuses on systems and structure; the leader focuses on people.
– The manager relies on control; the leader inspires trust.
– The manager has a short-range view; the leader has a long-range perspective.
– The manager asks how and when; the leader asks what and why.
– The manager has his or her eye always on the bottom line; the leader’s eye is on the horizon.
– The manager imitates; the leader originates.
– The manager accepts the status quo; the leader challenges it.
– The manager is the classic good soldier; the leader is his or her own person.
– The manager does things right; the leader does the right thing.

I don't necessarily agree with every point above. For example, I don't agree when he says that a manager has a short-range view and a leader a long-range perspective. A manager can be strategic as well as manage short term deadlines.

I often say that managers must lead their organisations to achieve the set objectives. A manager can also be a leader, and vice-verse.

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;



- user-friendly dashboard provides one view of theentire project allowing to see the real time information for all the project stakeholders;

- it's good for the team collaboration including daily stand-up meetings and remote teams management;

- it automatically creates charts, including release burn-down, iteration burn-up, story type breakdown, and historical velocity;

- it is available for the iOS platform (iPhone andiPad) and so on.

The tool is recommended by many Agile evangelists including those using Kanban, Scrum Lean and XP. But it's not the only solution on the market. New solutions appear with new additional features. Comindware is a good example.

Comindware

The tool is little bit more than just an Agile software. It combines collaborative task management with workflow automation capabilities. The main feature that allows Comindware to compete successfully with the other solutions is its 100% flexibility (or better to say agility). Project or process manager may create a specific workflow or edit predefined processes even in the middle of a project. The other interesting features used to manage Agile projects are:

- creating and assigning tasks (auto-generated tasks from workflows andtraditional task lists created manually), setting up their priorities;

- project team collaboration which is very essential while managing remote and virtual teams;

- real time status reports including priority, deadline and other reports that are very helpful during daily stand-ups;

- customizable visual dashboard that is perfectly used not only to create all possible types of charts and graphs but also to provide visual information to project stakeholders;

- portfolio management feature allowing to manage multiple projects and generate aggregated reports;

- easy integration (if necessary) with the other tools like SalesForceCRM and MS Outlook.

The Comindware solution may be used as a cloud-basedservice (more cost-effective option) and as a on-premise software (to get the maximum control). It's really a good solution with plenty of different useful features that go far over just an Agile project management. But for those who feel that it's too flexible and has too many features there is a VersionOne.

VersionOne

The tool is better known as a Scrum project management solution, but thanks to a big amount of functionalities it can be used for all Agile methodologies. I've listed the main reasons why managers prefer VersionOne nowadays:

- it allows to manage multiple projects and iterations at the same time;

- it allows to plan sprints and to manage requirements, user stories and epics using very user-friendly interface (I've even heard that some experts named VersionOne as the tool of the best usability);

- it may be used for the team collaboration (sharing files, ideas and messages);

- it allows to create visual burn-down charts, so as storyboards, trackboards,testboards;

- it may be connected with other tools used in software development projects like CruiseControl, Jira,
Bugzilla, TeamCity and etc. allowing better flexibility;

- it provides almost everything for a good reporting andanalysis because there are more than 50 agile metrics and reports, so as a custom analytics platform.

Instead of a conclusion:

Today we have so many software tools that even a very professional project manager may face a problem of choice. So, while choosing the best solution for your next Agile project don't forget the golden rule: a tool is nothing more than an instrument that has to serve the goals of your project and to help you and the team to be effective. As for me for my current projects I use MS Excel (simple on-site projects and to-do lists) and Comindware (middle-size and big projects, processes, managing remote teams).

Author
Hi, my name’s Steward Copper and I am the owner of Project Management Insights. While working as a project coordinator and BA, I have tried almost all possible PM tools, BA instruments, collaboration programs, including tracker and hr system solutions. I also write for different blogs sharing my knowledge and observations.

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.

As the head of IT you need to know the vision and mission of the organization, the products it sells or the services it provides, how it makes money, how it spends money, the competition, the industry, etc... The list is quite long and varies depending on the nature of the organization. The point here is to know everything you can about your business in order to enable you to be a valuable member of the board and/or the senior management team.

I have heard many IT managers complaining that they don't get a chair in the company board of directors and/or don't have opportunities to participate in strategic meetings. Maybe the reason that happens is because the CEO, CFO and other members of the organization perceive the CIO as only a technical resource. That limits the effectiveness of IT. The CIO needs to not only know the organization but he also needs to show to the other members of the senior management team that he can positively contribute to non-technical discussions.

Build a good track record

 

This really means do what you said you would do. Honor your commitments.  Your peers should be able to trust you. Ensure to deliver on every deadline. If you know you will not be able to get something done speak to everyone involved as soon as you can. People will trust you because you always do what you say.

Having a good track record will help you to build a good reputation and nothing is more important than a good reputation.

Quote your peers whenever you can

 

This is quite powerful. When giving credit to someone, you are giving someone else a good reputation. This is especially powerful if the person is present in the conversation. They will always be thankful to you and are likely to return the favor.

Think about it the other way. If you take someone's idea and quote it as your own, you are actually robbing them a reputation they deserve. Worse still, remember that people talk in organizations and that particular idea you are taking ownership may have already been discussed so others might know whose idea that is. People may pick up on it and it can actually destroy your reputation.

Quoting your peers, positively that is, will go a long way in building rapport with them.

Discuss your concerns directly with the people involved

 

It is very important to raise your concerns with the people that are involved in it. Say for example that you have a concern about a particular business practice related to complaint handling. You will look really bad if you approach your boss, especially if he/she is the CEO. The best option is to organize a meeting and raise it directly with the relevant people and not only raise issues but also propose solutions.

However, it is easy for IT managers to be perceived as nosy and wanting to solve someone's problem, or even worse. You need to be careful about the reasons you are raising the issue and try to make it relevant to IT as well. It is not a good idea to say that complaints are not been handled effectively unless your issue relates to IT and you can provide some sort of solution.

Be professional, speak calmly, accurately and concisely

 

In order to build good, professional relationships, it is important to be professional and consistent at all times. Your emotions should not dictate how you react to an issue. There is nothing worse than knowing that you have to deal with someone but you never know how that person will react because he/she has a reputation of being unstable.

Ensure to always be professional, polite and accurate. Most importantly, do not lie. Others can probably see through you so don't even think about it.

Ask insightful questions and encourage a response

 

There is nothing worse than being in a meeting with someone who keeps on asking irrelevant questions and is always interrupting others before they finish talking. It is annoying and a waste of everyone's time. Make sure you are not the one making those mistakes.

It is impossible to plan for every interaction with your peers, however when attending meetings, ensure that you know thoroughly the topic at hand and only ask meaningful and insighful questions. Don't waste anyone's time.

Listen to what people are saying

 

Have you ever been in a conversation and got the feeling that the other person was just not listening? This is even worse if it happens at work. When talking to someone or participating in a meeting, make the other people you are talking to feel that they are the most important people in the world. Give them your full attention, be interested in what they are saying, value what they are saying even if you think they are wrong.

It is only when you really listen to people that you are able to ask meaningful questions and have positive interactions.

Many other points could be raised on this topic, however the list above provides a good summary on ho to go about building effective professional relationships.

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

• Knows the product, the market and the competition really well.

• Is the CEO of the product.

• Takes responsibility for all aspects off the product.

• Manages himself based on the product's performance on the market.

• Takes responsibility for devising and executing a winning plan.

• Good product managers manage the product team and not every detail of every aspect of everyone's work. He/she knows how to delegate and manage the team effectively.

• Good product managers are focused on strategic decisions, ensuring that the product is flexible and adaptable to a changing business environment.
  
• Good product managers create lots of collateral to support the day-to-day operations of the team. He/she is not swamped by questions about the product and ensure that they are not the only ones that can answer questions about the product.

• Following from the previous point, good product managers equip their team to handle the day to day activities allowing them to focus on strategic topics such as market positioning, timing, etc...

• Good product managers focus the team on revenue and customers,

• Good product managers focus on delivering value to the market place and not on just matching the competition.

• Good product managers think about the story they want published on the press and they manage the press, not the other way around.

• Good product managers are disciplined and produce status reports on time.

The courtesy lecture I read today can be found here.

One skill that is vital for good product management is the ability to build good professional relationships. In this article I explain the importance of building professional relationships in the context of IT Management. The same principles apply to product management, in fact, these principles apply to any profession these days.

Whilst the following articles are not written in the context of product management, the principles apply. As a matter of fact, I believe that many product managers lack good planning and management skills which hinder their ability to really excel in their product management career.

•  Management theory and IT Management Part 1 - Planning
• Management theory and IT Management Part 2 - Organizing
• The effective IT manager, the importance of relationship management

 In essence a good product manager is the CEO of the product, knows how to manage the team, the press and ensures to deliver value to the market place.

What are your experiences in product management, what makes a good product manager in your view?

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

Optimistic - I ask each developer to provide me with an estimation of how long it will take to complete each story they will work on. This is the number that I use for the optimistic component.

To estimate the other components of the formula I use a combination of grading user stories by size and complexity as outlined in the first article. However it is not as simple as that.

I don't see estimation as an exact science and therefore blindly applying a formula will not work under all circumstances. However, the formula does provide me with a consistent estimation procedure that has worked for at least 10 years now.

Another variable that I use in estimating the development effort is my team's velocity. I have a detailed record of the team's velocity recorded against functionality deployed to production. This helps me to compare actual duration of completed user stories against the effort that was originally estimated and use it as a basis to estimate the effort to develop stories that are similar in size and complexity ratings.

So here is how I devise the numbers for the rest of the formula.

Realistic - I search TFS (Team Foundation Server) for completed stories with similar size and complexity ratings and take the actual time that it took to develop it as the realistic component of the formula. 

Pessimistic - It is hard to estimate what a pessimistic duration would be because of many different variables that come into play such as risks associated with the particular piece of functionality, complexity, developer  experience and many other variables. I have met some development managers that double the duration estimated as the realistic and use it as the pessimistic. I don't blindly assign a number to it, I try to take everything into consideration in order to come up with an estimation that makes sense.

I don't think that there is a formula that you can blindly take to estimate software development effort. It is not as simple as that as there are many components that come into play in effort estimation, project management and software development.

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.

Attitude

Attitude is by far one of the most important skills a developer can have.

We all have different strengths and weaknesses, we can't all be technical geniuses or specialists in every single area of software development. When a developer faces a technical challenge and "hits the wall", no matter how good he/she is technically, attitude will determine the outcome. A good attitude and the ability to stick with it until the issue is resolved is key in this situation.

What I find particularly annoying is a developer that lacks these skills and as soon as there is an issue he/she immediately starts to ask the other developers without even researching the web or the team's wiki. Having said that, when facing technical challenges, there is a line when one needs to decide to stop researching and ask for help. I don't like to see developers stuck and not ask for help. Once research is done and a solution is not found, there is nothing wrong with putting your hand up and asking for help.

Business Knowledge

Business knowledge is also very important to enable a developer to work productively. Whether you work for an internal IT team or for a development house, having good domain knowledge enables developers to better participate in design meetings and to decide what delivers real value.

The time has past when developers sit in the corner and writes code according to the specs without asking questions or participating in solution architecture and other related tasks. We are all doing agile these days and moving to self-managed teams. Against what many people believe, implementing agile and self management is actually very hard. In order to have self managed teams you need developers that understand the business and are able to have meaningful discussions without project stakeholders. Without domain knowledge this is practically impossible.

Furthermore, well developed business knowledge enables developers to question the completeness and accuracy of user stories, either before or during development.

Lack of business logic is actually very dangerous because the developer does not actually know what it is that is being developed and what value it delivers to the business.

I would say that domain knowledge and attitude are some of the most important skills a good developer needs to have.

Openness for discussion

There are many different ways to address a particular technical issue or to develop a new function item. In my team we have daily stand up meetings and longer design/review meetings depending on what is going on.

Every so often we hold meetings to discuss the architecture and/or the best technical solution for a particular issue or functional item. During these meetings we discuss what the is the best solution and we move on to implement it without wasting too much time. I find very entertaining to see the developers argue to have their opinions or solution implemented. My own entertainment aside, these discussions are very important for the ultimate quality of our work because nobody knows everything, it is when we all sit around and workshop ideas that the best solutions are implemented.

I need to be careful and manage these meetings very well. Once we agree on a solution I quickly move on to the next topic or I end the meeting. The overall process works well, it has increased team cohesion and even the quietest developer starts to participate which is a bonus to everyone.

It is a win-win situation for me.

Appetite for new knowledge

IT is always changing. New technologies are often released to the market, new frameworks and methodologies are reviewed and update. It never stops. In order to keep up with it, developers need to be curious and have a appetite for new knowledge. You never really graduate from uni if you work in IT.

I could keep on going and identifying many other skills like knowing your tool set and many others, however I will stop here because I think that, in broad terms, I have touched on what really makes a good software developer.

I find really amazing that after a quick search on the web, most of the articles on this topic highlight technical knowledge, the need for good tools, knowledge on how to use those tools and other related technical skills. Although these skills are very important, they do not make great developers.

When I interview new developers I often ask if they know a particular technology or tool that is not listed in their resume. If they say that they know I probe a little further and may even ask why it is not on the resume, depending on the circumstances. The good ones, those who often get the job, say that whilst they don't have experience working with this specific technology, they can learn quickly and become productive in a reasonable period of time. If I can find evidenced of it in the resume and I confirm during reference checks, that will be the developer that gets the job.

In conclusion, I don't think that there is a definitive list for what makes good software developers as it varies depending on the circumstances. In broad terms, I find that attitude, openness to discussion and business knowledge are some of the skills that will give developers the edge they need to succeed in their careers.