Milestones are like progress bar indicators for internal stakeholders’ use. They provide feedback on progress to everyone involved. In different software programs, I have come across at least three different progress bars: the first easily reaches 90% then stalls, making you wonder if it has stopped.
The second one just shows that it’s working and does not stall but you don’t know how much work remains to be done. The third one gives you the impression of accuracy because it provides a realistic estimate. Even if the progress bar indicates there is still a lot of time left, you tend to prefer it over other time bars because you know you have time to do something else. Let’s look on some aspects of tracing progress.
Your project is getting closer to a release deadline and you ask the lead developer, “How’s is it going? Are we going to ship on time?”
“Hmm, something has come up!”, she tells you, “I have done really great for the last 4 weeks, but today I found something no one thought about and the timetable slipped 3 months.”
What’s the chance of that happening? I’d say it’s a small chance. The reason is timetable slip-ups don’t happen at the end of the milestone or project. Slip-ups show up at the end. Yet they happen every day and every hour. As soon as someone answers an unexpected e-mail, rushes home because of a sick child, or tracks down an intermittent but catastrophic bug, slip-ups happen. The sooner you can identify how much time is left and prevent slip-ups, the better you can estimate time periods, assuring team members and stakeholders that the timetable is still reliable.
Within any group there are things to be done. The outcome of some challenging activities is more important than others for your unique project/system/organization. For your project to be successful, identify the key factors/positions for success. I recommend starting with identifying the different roles and responsibilities.
When you have identified key positions to be filled, investigate what abilities and experiences will make success possible. How can you minimize risk by recruiting people who have worked on similar projects or systems? Who has the ability to fill the position either now or later because they have the potential to become great at that role and position?
Many projects start in the reverse order. I have the following persons and resources, what can I do with them and who fits in what role? Person X is best suited as IT Quality manager looking after the process, documents and so on. You don’t start with roles have to fill. Person X might not be an asset at all for this project. It might work out, but when filling key positions, it might be wiser to cross your fingers and wish for luck.
What Might the Key Positions Be?
It is difficult to come up with a general answer. I’m mainly looking for two different factors – managers and very specialized roles. There will probably be fewer of them than the rest of the team so it is more important that you get the right person. It might also vary over time, when a project is small and the key positions are mainly developers. However, later in the technology life cycle, it might be the product owner or project portfolio manager/assistant.
Hiring for Key Positions
There are a few general recommendations for hiring for key positions. If you can match people, roles and projects perfectly, I’m confident you will have a much better chance for success.
Values - Does the person share the core values of the organization/project/company? You cannot teach key values to people just to make them fit in. As Harry Truman once said, if people don’t know right from wrong when they are aged 30 they probably never will. You cannot teach people the right attitude, you can only teach them the right skills.
High standards - Look for people who you don’t need to manage. If they tend to have high standards from previous work they tend to exhibit the same high standards. People with low standards look for the easiest way out, they’re into short cuts. The quality of their work shows these low standards. You will have to define what’s expected from them and they need constant supervision and control. Your job is easier if you work with team members who maintain their high standards.
Ability - Does the person have the ability to become the most suitable person for this key position? He doesn’t have to be the best suitable right now, but does he have the potential to become the best suitable person in the future?
Neurotic responsible – don’t hire someone for a key position, hire for a key position responsibility. It’s important that a person doesn’t think of the work as just another job. He must think of it as a sacred responsibility. You want a person who wants to fix a hole – even be neurotic about it – as soon as he spots a hole. They won’t rest until it is fixed. This is an ability that you can’t detect immediately, but over time, you will be able to identify these neurotics who take their tasks very seriously. They’re the ones you want in your team because you know they won’t let problems fester and leave them unsolved.
How to Manage Key Positions
When you recruit people for key positions, invest the time to know them right from the beginning. Getting to know people and their abilities is a challenge so make the effort to know them, their work habits, their values and their strengths and weaknesses.
People are different so it’s good practice to be 100% familiar with these differences and how to handle them. A key position person is like a captain or helmsman on a boot. They give clear orders and steer the ship away from dangerous rocks. Each person on that ship may be following orders, and meeting targets, standards, and plan. But what happens if these targets, standards and plans are wrong?
Ask yourself: do I have the right seat or do I have the right person in the wrong seat? Maybe another position would be better? However, if you had the good fortune of hiring the right person for the right task, so whatever it takes to motivate, coach and develop them.
To understand how knowledge is spread throughout an organization, we need to understand the SECI modell by Prof. Ikujiro Nonaka (Hitotsubashi University). When Prof. Ikujiro Nonaka introduced the SECI model (Nonaka & Takeuchi 1996) it became the cornerstone of knowledge creation and knowledge transfer theories. He proposed four ways to combine and convert knowledge types, showing how knowledge is shared and created in organizations. The model is based on two types of knowledge – explicit knowledge and tacil knowledge. Explicit knowledge is visible knowledge, it is easily explained, quantified and documented; tacil knowledge is unseen and grows with habits and hands-on work, but is not easy to share or document it.
The model also consists of 4 different process situations: Socialization, Externalization, Combination and Internalization.
This process focuses on tacit to tacit knowledge transfer. It’s done when knowledge is passed on through practice, guidance, imitation and observation. This is when someone who is learning a new skill can interact with a more experienced person, ask questions and observe. This occurs in traditional environments where a son learns the technique of wood craft from his father by working with him (rather than reading books or manuals on wood working).
Externalization This process focuses on tacit to explicit knowledge transfer. Externalization is about making an internal understanding more quantifiable like writing documents and manuals, so that the knowledge can be spread more easily through the organization. The processes of externalization are good at distributing knowledge for repetitive work or processes. An expert describes different parts so that readers can understand “if this happens do the following in order to succeed”.
Combination The process of combination is about transforming explicit knowledge to another person’s explicit knowledge. A typical case is when a financial department collects all financial information from departments and consolidates this information to provide an overall profile of the company.
Internalization The process of internalization is about transforming explicit knowledge to tacit knowledge. Through reading books, manuals or searching on the web, explicit knowledge can be learned.
There is a spiral of knowledge involved in their model, where the explicit and tacit knowledge interact in a continuous process. This process leads to creation of new knowledge. The central thought of the model is that knowledge held by individuals is shared with other individuals so it interconnects to a new knowledge. The spiral of knowledge or the amount of knowledge grows all the time as more rounds are done in the model.
The basis of all change is that the need for change is known and communicated. If it’s not on the agenda it will probably not be valued. If spreading of knowledge is important for your organization, talk about it with the people involved.
Everyone who is affected by the project will have an opinion on how the project will affect them personally and their organization. Users want the best software and customers want it for free. Sales people want a unique product that creates a great business value for as many potential customers as possible. Suppliers want a larger share and your development team wants to use only state of the art tools and technologies. Your responsibility as a software development manager is to make sure that the right thing gets done, in the right time and in the right way. To make this happen understand the needs and strategies of the different stakeholders.
The responsibility of the software development manager, therefore, is to make sure that everyone gets what they want. This makes him the middle man negotiating with all stakeholders. Your aim is to give everyone something – so they feel like a winner. This is one of the main subjects of this book and I discuss it in another chapter. For now I just want to make clear that making everyone happy to a certain extent is a key role of the software development manager.
The following conversation is typical between a manager and developers:
Project manager: How long will it take you to develop this specific feature?
Programmer: One month of uninterrupted work
Project manager: Oh, I need this done faster. Can’t it be done in a week? Need this before next month’s fair.
Programmer: It might get done in three weeks.
Project manager: Two?
The project manager will note the estimate of two weeks and will hold the programmer accountable for it.
So what was this discussion about? It’s about three different concepts: estimate, business targets, and commitment:
An estimate of work is based on a calculation of quantity of the value of something. How long has this type of work taken to complete before or what do the different parts cost and how long do you need to assemble them? The estimate is used to decide if the work is worth doing or not.
A business target is a desirable business objective, “I need this before the next month’s fair.”
A commitment is a promise to deliver by a certain date or event.
What the project manager wanted was a commitment based on a business target, not an estimate. This is now a commitment but don’t call it an estimate. The estimate was 4 weeks. What happened was that either the scope or quality has changed or the programmer worked more hours than he originally planned.
Humans have a need to feel that they are in control. Control is a profound need. When we feel out of control, we experience a powerful and uncomfortable tension between the need for control and the evidence of inadequate control.
From an evolutionary standpoint, if we are in control of our environment, we stand a far better chance of survival. Our subconscious mind thus releases certain chemicals when faced with danger. The only time we will feel a sense of control is when we understand how things work and we can predict what will happen.
So how much control can you expect in different situations?
In financial markets, you expect a 1-4% return if you want to stay in control and take a small risk. But if you want higher returns, you must be prepared to take more risks. When you take more risks, you lose control at the same time.
The higher the stakes are and the more pressure you feel, the more sense of control you will need. If you have more responsibility than authority, this can frustrate you. You feel the need for more control, and this in turn creates stress.
Running a complex project means that you’re aiming for more than 1-4%, and are willing to take a larger risk. To demand that someone be in control only creates stress. To gain more control and to be able to plan far into the future are only possible when you take more risks. To think that you can stick to a pre-drawn map that does not take into account the fact of control creates frustration and friction. The feeling of control in complex projects comes from breaking down all activities into smaller segments and making detailed short term plans. Don’t expect long term planning to work.
What’s my conclusion on the question, why is it difficult to plan for success in software development?
Reaching Maximum Business Value
When work is more of an exploratory journey, your work is to solve problems you don’t yet understand by creating a solution that you also don’t yet understand. At the same time, you should communicate with people in a language you haven’t yet learned. Because of these “unknowns”, the work is complex and there is a lot of noise. The noise interferes with your information in such a way that you can’t distinguish the message from the noise.
In this situation traditional plan-driven processes that try to predict the future will only give you a false feeling of control. To control this situation you will not be producing the best solution since you will steer to your perception of what the customer wanted in the beginning of the project.
During the journey, however, the customer got wiser so that the original goal is no longer good. The customer now wants the benefits of the knowledge he acquired during the journey. By organizing work in different ways, you are actually getting more business-oriented and you’re lowering the risk.
Projects often start because someone realizes that there is a new opportunity or that we need to fix something in order to save money. An idea soon becomes a requirement list and then the “innovator” convinces a manager that this might be something. The manager then contacts IT-people to get there view, what might the thing and what could be done. The “IT-People” realize that this is no out of the box solution, but this requires a unique system. The “IT-people” starts to write a specifications and talks to different stakeholder and then come back to the manager that first contacted team and asks “What if you add this and do that?” The manager answers “Ooh nice, can you also do this then” and so it continuous. And the specification just grows into a bigger plan. At this point the organizations seams to choose path to continue, either the plan-driven; phase by phase way or the agile let’s start solving some problems and see what we learn.
Now I’m probably a bit provocative but the problem but I think the plan-driven companies would probably end up with the right wrong system and the agile will probably just do it faster. The problem is that you are not solving and focusing on the real business problem, the IT-People have a tendency to start to focus on technical features. The most users will start dreaming up all kind of new features that you could do and be nice to have, but really doesn’t give any business value. Instead the most important thing you should do is to study users or future users how they would perform the action manually. Involving users early is a real key success factor, and then the important thing is to see what they really do and how they might use the system not what they think they might use and nice to have features. Cost savings driven project are more easily investigated. New opportunities driven projects are often more difficult to involve user feedback within, this is because people can’t as easy relate to something they don’t have experience with.
In the earliest period of industrialism, Taylor and Fayol created new ways of administering work more efficiently by centralizing power. Earlier, I talked about the planning, organizing, staffing, directing and controlling model. The foundation of this model was that uneducated labor was hired in factories and they where managed by people who controlled the whole process. This was based on the assumption that the manager knew more than the laborer.
The style by which these managers led others echoed the dictatorial style of “you do it my way or you don’t do it at all”. As the labor force became more competent, the managers’ roles shifted. Managers learned to delegate parts of the working process in the new “Empowerment style”, “Do this but do it your way…”. When power was decentralized, the creative and innovative energy of employees was released. Management trusted employees more and mistakes were regarded as part of the learning experience.But in a more complex world where the future was more uncertain and managers didn’t know “what should be the right thing” or “How the right thing was done” a new way of management came about. With Toyota as one of the biggest examples of Kaisen and Lean, everything will improve and will be done just in time. Consequently, management had to change into “follow me and let’s figure this out together”. It became an exploratory journey. We can’t fully understand the problem until the first solution to the problem is delivered. And we won’t know if it is the right solution. The right solution (what) is discovered along the way and solved in ways never done before (how). Therefore, what is needed to succeed in this trip into the unknown? This approach enabled Toyota to implement a million new ideas a year. This is why Toyota made more than twice the money as any other carmaker. Toyota has truly demonstrated what a culture of creativity and innovation can do.
A new kind of “manager”
In traditional non-knowledge-based companies, the title of “Manager” often implies that a person is either responsible for a lot of people or earns a high salary, or both. Nowadays, there are a lot of managers that have neither formal power over people nor earn higher salaries. instead they are responsible for a specific situation.
They are assigned to be advocates for a specific intention, area or goal. Within this goal, their responsibility is to understand what makes this intention as successful as possible. A project manager is someone who is responsible for making an intellectual journey into the unknown, taking a specific context from one starting position to a much brighter and more valuable future.
Management these days is about taking responsibility for a situation. In Jeffrey Liker’s book “The Toyota Way” Toyota’s leaders are described as leaders who are clear about the purpose and direction; at the same time they remain close to the business and have a deep understanding of the work. A manager needs to have a deep understanding of the Value to the customer. The value consists of “the right thing” for the customer and that the work is done “the right way” for the customer.
The Agile Reaction
Agile methodologies have been around for a while and have been adapted with varying degrees of success.Agile methodologies constituted a reaction against the more document-driven and plan-driven methodologies like RUP. But Agile work was also a reaction against the traditional way of management (bureaucratic management and task management).
Software development is true knowledge-based work, which means that the persons in the team doing the work know most about the whole system, not the managers as in a factory. This puts the managers in a new role where other things are demanded.
The Agile Manager – the Knowledge-based Work Leader
If management is more about taking responsibility for a specific situation, value is created primarily by the team’s knowledge and creativity. A friend told me a story about curling. Each curling team consists of 4 players and one is the team leader. Everyone in the team plays stones and helps out with the sweeping. The manager leads the work with the strategy, discussing with each member but at the same time is an active player himself.
Sometimes the players need to get on the track and help the other players out, sweeping in front of other players’ stone to give it the right speed and direction. Agile management is similar to this. the Agile manager is the player that helps out with the knowledge-based work but his most important responsibility is to help others perform as much as possible and to focus on strategy and execution.
When I look at myself and my work, the times that I feel becoming engaged in the “production and operations”, I soon lose sight of the macro perspective of the development.
Answer: because software development is more of an exploratory journey than looking up information or formulas in a table. You will of course need to know your tools so you can deliver but in a world where more and more people have university degrees and anything can be looked up on the Internet, the value of knowledge (What, Why and How) decreases.
If software development was more like traditional engineering, you would look for solutions in books or on the net. But repetitive needs are already boxed like Microsoft Office or enterprise systems like SAP which are available in the store.
Management is about getting things done. When you stand up for an idea you risk making a fool of yourself at least until you convince the first people. Until you convince another person, you are just a person with an idea – you’re alone. But as soon as you convince one more person you are at least two crazy people and you both gain momentum.
I often feel empowered when I am able to convince the first person. When the second and third persons believe in the idea, it feels like a group and enthusiasm fills the group. The fact that you feel insecure when presenting new ideas means that others feel the same. As a leader it’s important to stand up for other ideas if you believe in them, and especially when not many believe in the idea.
A real leader is brave to be the first follower to get others to believe in the idea. When you start following others, you show your support and also show others how to be followers.
The moment you begin to think this way, you lose it (this is called hubris). The key driving force to becoming great is to always want to do better. This is an important lesson to learn. If your team members always think they are better than anyone, observe their thought patterns. When humility is absent, your members will lose the ability to become greater. This doesn’t mean that you shouldn’t celebrate success and goals. It means celebrating victory the right away. Celebrate a goal but don’t let them think that it has been accomplished, instead make them reflect on how they could do even better next time. How do we do this better?
Here’s a Dilbert story that someone told me. Unfortunately I couldn’t find it so it might not be an original Scott Adam story.
Dilbert: Can I work from home?
Pointy hairy boss: How do I know that you will be working?
Dilbert: How do you know that I’m working when I’m at work?
Pointy hairy boss: When you are here, you seem to suffer so that probably means that you’re working!
When you ask people where their best ideas come from, they seldom say “at the office.” I usually come up with new ideas after leaving the office or when I’m not there. If you’re leading a team where creativity is a key success factor, it’s a good idea to ask your staff where they’re getting their best ideas. Maybe not all of their work should be done at the office. Ask what suits them best.
With my team, we usually plan to work at the office together for at least a couple of days in the week, but it depends on what phase our project is in. In the beginning stages of projects we discuss a lot of things. At the end of a project, we need to have quick and easy access to each other.
Some members of my team prefer to work at home when they can, and some put in longer concentrated hours so they can work from Hawaii for two weeks and combine work with vacation so they can extend it to a month. I like to be flexible and change my work environment – I spend 2-3 mornings a week at a café across the street from work (my office Wifi even works there) and at lunch I’m back in the office.