Setting clear goals are important but the current fixation of the SMART goal setting strategy might be needed to be reconsidered, at least when you lead competent co-workers. You have probably been drilled in the SMART goal setting strategy, which preaches that goals shall be Specific, Measurable, Attainable, Realistic and Timely in order for people to be able to strive for that goal. I want to raise a warning finger when you working as a manager in a knowledge-based organization, you need to be very careful what you which for, you will probably get it.
When you lead competent coworkers they probably know more than the managers, therefor it might be hard to create both short term and long term success based on SMART goals by someone that is just based on historical behavior without getting an undesirable side effect. They might not know witch goal to be set or how to reach the goal but they have a far higher ability to adapt their way of work and invent new solutions than what a reactive SMART goal would lead to.
Let’s say that you like to decrease the “hardening” time at the end of a release cycle. Therefor a SMART goal is set to “cutting the verification time by 50% within the next three iterations”. This target goal will probably be reached, but often at the expense of more defects getting through to the release.
Another approach is to challenge the team to redesign the way development works so that defects are discovered and fixed as soon as possible after they are injected into the code. With this challenge, a team would quit focusing o how many feature are delivered and start thinking about how to make sure that every delivered feature is defect-free. The team would introduce practices like automated test, continuous integration and code reviewing. When done well, this approach has a track record of dramatically decreasing testing time, by far more than half and at the same time raising quality and productivity. The system verification time was just an effect of how the development was conducted. If you only look on the verification and test time it might be easy to not see the whole cycle and just trying to make the tester more effective.
The point is that goals that are SMART often are reached, but often solved in a reactive way that leads to new side effects. When you lead competent, proficient and expert coworkers they have an ability to reach further than the SMART goal, when they are given a challenge that is open-ended.
A Challenge is different from fixed performance targets:
- Challenges are not necessarily SMART; they are open-ended, customer-centric, and designed to elicit passion and pride.
- Challenges communicate confidence that the team is intelligent, innovative, capable of thinking for themselves, and trusted to do their best to further the purpose of the organization.
- Challenges flow from long-term vision of what is necessary to be successful over time and contain enough information that the team can act independently and with confidence that their work will contribute to achieving the vision.
- Thus challenges are a pull from the future rather than a forecast of the future.
As I said earlier, knowledge-based work is more of an endeavor than an execution of a well known process. When you undertake a task or project that you’re not sure about, it’s natural to feel some hesitation and anxiety. I have felt this way with some projects, blaming myself. I attributed the pain of loneliness and anxiety to my personality defects – I thought that I lacked certain traits others had.
When I discussed my doubts with friends who are studying to become journalists, they advised me to read The Writer’s Journey by Christopher Vogler and Himmel-Helvete tur och retur (English translation: Heaven-Hell and Back which is available only in Swedish) by Bengt Renander (a Swedish creativity consultant).
In The Writer’s Journey the classic storyline for drama is discussed – how do you build a story that will work in dramatic movies? Vogler, who worked in both Disney and Warner Bros as a screenwriter, divides all dramas into three parts that have twelve different steps or actions. To build a good story that people will like, he shows how most movies are made as exploration journeys, where the main character in the film faces a challenge or needs to resolve a conflict. This takes the character through the following twelve steps.
Vogler divides a story in two different worlds: the ordinary world where you first meet the main character and then the special world that he is about to enter during the journey. In the ordinary world the main character is living his ordinary life. For example, you first see Luke Skywalker, the hero of Star Wars, who is bored to death as a farm boy before he sets out to tackle the universe. If we continue with Star Wars as an example, we proceed to the next stage – the Call of Adventure – when Princess Leia’s sends a desperate holographic message to old wise man Obi Wan Kenobi, to ask Luke to join the quest.
Leia has been snatched by evil man Darth Vader, much like Greek springtime goddess Persephone, who was kidnapped to the underworld by Pluto, lord of the dead. Her rescue is vital to restoring the normal balance of the universe. As the story continues, Luke refuses the call of adventure by returning to his aunt and uncle’s farmhouse, only to find they have been killed by the Emperor’s storm troopers. Suddenly, Luke’s reluctance transforms into a burning desire to undertake the quest.
Luke takes the evil of the Empire personally. He is motivated. Those of you who saw the movie know how the story continues. The interesting observation in this structure was made by Bengt Renander who realized that behind all these steps lies a specific feeling that the viewer is supposed to feel. The reason this technique works for many movies is the common order of feelings that humans have when undertaking an exploration journey and when they leave their comfort zone. As Bengt puts it, “a movie where the main character doesn’t develop emotionally will be rather boring to see”.
Bengt also realized that it’s a common misunderstanding is the best result comes when there are feelings of lust and creative joy. All these feelings are necessary – indeed normal – in creative processes. They’re not wrong – they’re feelings that just stir within us. In fact, they are signs that we are on the right track. Feelings of pain are normal in the creative process and that’s a consolation for all creative workers who are aware of that.
Put this into a team and you as a project manager don’t need to feel frustration, anxiety and anger. You know it’s not your fault, because it’s part of the process. When you leave your comfort zone and undertake a project that is complex and hard to do, it would be strange not to have these feelings.
A friend told me that early in his career, he worked in a juvenile detention center and used to have talks with his supervisor about what he disliked most about his work. The hardest thing is to isolate people from society against their will because this goes against human nature. His supervisor answered, great! What kind of prison would we have if all guards felt that way?
The moral of the story is that it’s natural to be afraid and anxious when leaving one’s comfort zone. The more complex a project is (no agreement on requirements and/or uncertainty about the technology) , the less one’s previous experience can help.
Longing is the foundation of all creation.. Longing works like a radar – if you long for a new and better job, you will probably open your eyes to new possibilities. If you are longing for a relationship, you will be more open to new and interesting people.
When an idea introduces a possible solution, longing is replaced by arousal. Longing is about wanting to change reality (today something is in a specific state but it might be different in the future). The definition of a problem could therefore be, “the problem” = “what you want and long for” – “the reality”. The larger the difference between “what you want” and “the reality,” the larger the problem is.
The more accurately you identify “the problem” the higher the chance of a successful solution. If the problem is that it is too cold in Sweden, you like to travel to a warmer place. The direction is to go south. To define the problem is to set a direction of where to go. If you set the wrong direction, the problem will not be solved, even if you compensate by working faster.
If the problem is the lack of previous experience, hesitation sets in. This is because undertaking a new endeavor means travelling into the unknown. The unknown connotes that danger is lurking and you don’t know what will happen. Your choice is to leave your comfort zone or to hesitate. Interestingly, either choice will cause pain.
If you decide to not start the journey and stay put, you will cause regressive pain, creating anxiety that comes from self-betrayal, from not exploiting your potential. If you decide to continue forward, it will also cause pain – progressive pain. You do not think you can handle the mission with your knowledge and experience. This is a form of growing pain.
Hesitation is natural because you’re considering the risk of failure. The ability to plan and make calculated assumptions about the future is what distinguishes man from animal. Previous experience enables one to draw conclusions about the future. Without any previous experience and the possibility of losing something creates worry.
To overcome hesitation, motivation is needed. Motivation comes from the belief that the satisfaction of reaching the goal is larger than undertaking the journey – including the fear of failing. One can define motivation therefore as the “motivation to do something” = “The expected satisfaction of reaching a goal” – (“the cost of doing the journey” + “the fear of the risk of failing”).
I have heard many entrepreneurs say that they never would have started their endeavors if they knew what they were getting into. Thanks to that they underestimated “the cost of doing the journey” they become more motivated, so ignorance can be a bless.
Just when you had hoped to get started on your journey, you get that feeling of emptiness. You have to let go of something old without having something new to keep you in. The task seems endless and elusive, you do not know where to start and nothing feels like a natural start. This gap you feel needs to be filled with ideas on HOW the trip will be made.
To get ideas about how the trip can be accomplished, you need inspiration. Vogler calls this phase meeting the mentor in his book Odyssey (700 BC). Odysseus leaves his son Telemachus with his best friend when he goes to war against Troy. The friend’s name is Mentor and his name has become synonymous with helping others to develop.
You do not need a mentor to find some inspiration. The word inspiration comes from “Spirit”. To become inspired means to nourish your soul, you breathe in and fill the emptiness.
Transition from Act 1 to Act 2
In Act 1, you defined the problem, weighed the advantages and disadvantages but does not inspire you. The question is if you are motivated enough to want to solve the problem. Act 2 is about facing your own barriers and limitations.
When developing complex systems the difficulty comes from not having done them before. It could be that the technology and application are new to you. Or, the domain is unfamiliar that you have to learn the prerequisites of the business or you don’t know the persons you are working with. In most cases, all three of these factors are in some degree new to you, so you need new knowledge to succeed. As you learn new things (tools or information about the domain) you gain new insights. This gives you a feeling of enthusiasm.
Developing complex IT systems is a highly collaborative activity. When you’ve figured out the solution, the next is to sell this solution to others. You will need to motivate your thoughts and also adapt to new thoughts. Vogler calls this the phase of tests, allies and enemies. Like a film, the project also needs to be aligned so that everyone’s efforts are pointing in the same direction.
This is a very frustrating process. You had problems convincing yourself, now you have to convince others. This makes creative work that depends on collaboration more frustrating than working solo. Collaboration is a core concept to take into account when working on complex software development projects.
In Vogler’s work, the hero’s journey is described when he approaches the innermost cave where the battle is to be fought. The hero is starting to realize he will have to face his worst nightmare; the fear of dying is pronounced. During the creative process the same thing might happen to you when you realize that this journey is taking a road you are afraid of. A line that is frequently heard in films is, “I would do anything to succeed without this”. In the film Return of theKing (The Lord of the Rings) we listen to Gandalf and Peregrin Tok talking on the night of battle where Gondor is waiting to be attacked. Peregrin Tok says, “I don’t want to be in a battle, but even worse is waiting for a battle you can’t escape. “
All you do is wait, and the only thing you can do is to prepare. Defense mechanisms are triggered. The project’s orientation is about to change, or your role has changed into something you do not want. Your self-image is clearly an issue; you are afraid because you know you have to change.
Pressure from others leads to self-doubt. I’ve been through situations where people came to me in anger and threatened to resign if the system was not designed in a certain way. The person’s anger was caused by two things; first, questioning his role as architect, and second, wasting his investment in terms of time and commitment because of the change.
In movies, the dramatic high point is the last battle for mankind or the final battle against the star’s death. As Conan put’s it “enough talk, let’s kill!” Vogler reveals that the big secret of “the ordeal” is that the hero must die so that he can be reborn. In the creative process, we will have to accept change. You accept to let go the old baggage go, otherwise you will be doomed to failure.
In Bengt Renander’s book, he tells the story about how monkeys are hunted in south India. The hunter drills a hole in a coconut and then the coconut is chained to a tree. The hole is just big enough so a monkey can stick his hand in. Inside the coconut are some grains of rice that the hunter put in.
During the night, a monkey puts his hand inside and grips the rice grains but can’t get his hand out. On the morning the hunter returns, but instead of letting the rice go and running away, the monkey continues to try to get the rice out.
On the physical level, the monkey won’t let go of the rice. But his mental picture of himself is that even if chained, he is still a creature that thinks food is important. The monkey realizes that this mental picture will spell his doom.
It’s the same with software development projects: if you don’t accept change and you don’t adapt, you will be doomed.
For as long as you accept change, you will manage. When you have changed your mental picture of the problem, that’s when ideas come to you. They pop up, often when you’re thinking of something else. Ideas come when you leave your cubicle. In my case, ideas come when I’m in the car on my way home or when I’m about to retire for the night.
The idea is crystal clear in your mind and you see relationships you didn’t see before. You will feel an excitement to experiment with it right away. In the beginning of this book, I wrote about enthusiasm and how it is best used as soon as possible. If you get an idea today, how motivated will you be if you don’t start it until next week? The idea will probably not give you the same energy. Many people think that it is at this point where the creative process starts.
Act 3 is about making it happen in movies. It’s the point of no return, it’s the road back to normal, but it is not the same normal you came from. It’s a new normal. It’s now the idea it will become reality? Are you motivated enough to make the idea a reality? If Act 1 was WHAT and Act 2 was HOW, the last act is “ACTION”.
In a creative process, the most important thing is delivery. If you know how the feature and its dependencies shall be constructed, it’s time to build it. All creative work is characterized by a craftsman based realizations phase. Otherwise the output of the work had been reproducible with the same input. This is one of the things that motivates people. When done the same way or doing similar things several times, creative motivation disappears. Nothing wrong with that. Personally, I think it goes in periods. If I have a high level of complexity in my personal life, I can’t handle as much uncertainty in work. Since complexity and creativity are causing uncertainty and stress, it may be too much to have it on all fronts. People are different, some can handle more stress and uncertainty than others, and their ability to handle stress varies with time.
You must adapt your idea to reality. The idea will not become as ideal as it was in the thoughts (the Platonic world of ideal forms); we need to fit idea into other real concerns. The ones that are angry when the idea is adapted to reality are the ones that worked with the idea, it’s their idea that has to adapt. People who haven’t been that involved and haven’t invested any time in working the idea judge the idea only by the end result.
When an idea becomes reality and “the problem” no longer exists, you are relieved and at peace. You have now solved the equation of “what you want and long for” – “the reality” and it is rewarding.
A project shall deliver something “a scope” on a specific time and to a predictable budget. As your project progresses, things happen differently from how you’d planned. You find that you need extra computer hardware, and some tasks have taken longer to complete than you originally predicted. To get the tasks completed on time, you consider recruiting more contractors. But, to do this, you’d have to take other costs out of the project’s budget. You think about not buying the extra computer hardware that you need, however, this would mean changing the project’s scope, so that some functionality isn’t delivered. In many projects, the budget, scope and schedule are closely linked. Changes to one of these three key constraints will most likely affect the others, or impact on the quality of the project. In order to plan and manage the project you will need to know how the customer will prioritize. They probably say they need the entire scope on time and on budget. But here is an advice to see how the customer really is going to prioritize when things will not follow the plan. When planning the project you ask your customer or product owner the following: “its two week until delivery and the two most prioritized features are not finished, what will you do?” Does he say do whatever it takes or never mind that feature or how much more time will you need. Or he might say takes as many shortcuts as you can. This gives you an idea of how privatization will be in when things starts gets pressured.
Different prioritization themes
It’s rare that we have the time to everything we need to do, so we need to prioritize. The agile methodology is preaching that you shall prioritize to maximize the business value, but often business value is something vague. And at the same time you should prioritize knowledge acquisition and risk minimizing. I will introduce you to four different prioritization themes and show how you can use them and combine them in order to know in which order you shall implement your project.
- The financial value of having a feature.
- The cost of developing (and supporting) the new feature.
- The amount and significance of learning a new knowledge created by developing the feature.
- The amount of risk removed by developing the feature.
Because most project are undertaken either to save money or to get new opportunities for making more money, these first to factors often dominate prioritization discussions. However, proper consideration of the influence of learning and risk on a project is critical if we are to prioritize optimally.
How much money will the organization make or save by having this new feature. This is often what is meant when products owners are given the advice to “prioritize on business value”. The ideal way to determine the value of a feature is to look in its financial impact over time – usually the next few month or possible years.
In order to judge if something is worth doing you must weigh value against cost. Many features seem wonderful until we learn their cost. When considering cost is important to evaluate the cost over time, some features cost more to maintain than to build. Adding language support might be cheap but slow us down and cost a lot to maintain. It might be better to wait with that a couple of month.
In complex projects much of the overall effort is spent on perusing new knowledge. The knowledge can be either what shall be done or how it shall be done. If the team has no prior experience of something, start as early as possible with that task. You can do a proof of concept and it will help you to uncover the borders of the technology you using. It could also help you to agree upon requirements, because when people see how the programmer interpreted the requirement you’ll be able to see if it is what the customer expected. If the customer or the stakeholders don’t react, that is also good news – that mans they thing you interpreted their view.
By prioritizing features that have a big impact on the system and develop them iterative and deliver the system to users frequently helps you to learn new knowledge. Complex products biggest risk is probably the risk of building the wrong product. This risk can be dramatically reduced by developing early those features that will best allow us to get working software in the hands of actual users.
Risk is all about the knowledge you don’t have. A complex project becomes complex because we don’t know “what we going to do” and “how we are going to do it” and at the same time have a lot of expectations on what the project shall accomplish. Risk is anything that has not yet happens but might and that would jeopardize or limit the success of the project. There is many kinds of risks they can be outside the project “What happen with the system if the company is split?” it can be a schedule risk “If this doesn’t work we will not be done by April” or a functional risk “We might not be able to get that to work”.
There is a classic struggle between high-risk and the high-value features of a project. Should the team start on high-risk features that have a big impact on the system, the things that if they go wrong have many dependencies to all part of the systems and just must work. Or should the team focus on the low hanging fruits, which will deliver most bangs for the buck?
Conclusion of prioritization
There is no ultimate way to prioritize! But it might be good not to just look on one parameter like value or value/cost. And the preferred method should probably link to the project main enabler, saving money or getting new opportunities. You can also combine different aspects like risk and value.