In a world with endless opportunities for information overload, people tend to get pickier about what they spend their time on. Their time is limited and they need to concentrate on relation they value. So who is valued in the knowledge based economy?
In the book “Netocracy” the author Alexander Bard coins a saying that is “Attension value” is the credibility something’s have times the attentions it gets. In order to something to get valuable it need not just to be serious and unique it also need to get a lot of attention.
Value in the knowledge based economy comes from your attention value. Attention value is credibility times the attention something get. Things and ideas that are new and unique, that could be the next big idea. Things that are credibiitiezed but not known are the things people is looking for the next big idea.
The technology adoption lifecycle is a sociological model, based on research of discontinued innovation in the 1950s. The model shows how new innovations are adopted over time and their selling points over time. The model is graphically represented as a bell curve:
The model divides the adoption of technology by customers into five customer segments:
The Innovators = Alpha nerds. They are fundamentally committed to new technology within their field of interest. They are always updated on the next version and know when the next beta/CTP version is released. When products are in RTM (released to the market) they are already experienced users. When the technology becomes mainstream and commonly accepted, they have already moved on. The alpha nerds follow specific blogs and discuss products in specialized forums. They take pleasure in mastering product intricacies, just by fiddling with it. They love getting their hands on the latest and greatest innovations. From a marketing point of view, however, particularly in business-to-business sales, there is one drawback with alpha nerds. They don’t have the money. What’s important about this group is their influence; they are gatekeepers to the rest of the life cycle. If something is rejected by the alpha nerds, no one gives the product a second glance.
The Early Adopters = Visionaries. These are the true revolutionaries in business. They look for new capabilities that give them the competitive advantage over the old order. The visionaries have more money because they see this as an investment: they either save on costs or obtain new opportunities. The visionary tends to get involved and spread word about the product – “look what I found.” Visionaries demand special modifications that no one else dreams of using. These demands quickly overtax the R&D team.
The Late Majority = Conservatives. These customers are pessimistic about their ability to gain value from technology investments. They are very price-sensitive, highly skeptical, and very demanding. Rarely do their demands get met, in part because they are unwilling to pay for extra services.
The Laggards = Skeptics. They are very conservative. If they buy something, it’s nearly against their will, and someone else makes them do it. They are not so much potential customers but more as critics, quick to find what’s not good with change.
The technology adoption process strategy can be described as
Start seeding information about the product with the technology enthusiasts so they help you educate the visionaries.
Once the visionaries’ interest is captured, do whatever it takes to satisfy them so they are good references for pragmatic customers.
Focus on becoming the market leader in the segment or the de facto standard.
Generate revenues by serving the pragmatists and re-organize for volume sales.
Use the influence of the pragmatist to generate sufficient volume and experience so that products become reliable and cheap, meeting the needs of the conservatives.
And for the skeptics, leave them as they are. Don’t waste your time on them.
The Chasm Theory
The technological adaption process was a very widely spread theory and was the basis for marketing strategy of new products up until a marketing consultant named Geoffrey Mo0re noticed in the 80’s that companies kept stumbling every time they transitioned from being visionaries to pragmatists. He realized that the early adopters and pragmatists were so different in terms of underlying values. The groups had too many differences between them that it was hard to reach the pragmatists in the mass market.
Geoffrey Moore summarized the difference between the two groups by using the phrase “I see”. When visionaries say “I see”, they do so with their eyes closed.That’s how visionaries see. Pragmatists, on the other hand, like to see with their eyes open. They don’t trust visionaries for the same reasons that they don’t trust people who want to navigate using the force.
Visionaries are intuitive and take more risks whereas pragmatists like to see facts that they can analyze and use to calculate their risks. Moore discovered that by the time the high-tech firms were getting this far into the market, they were so highly leveraged financially that any hiccup or bump on the road would throw them into the Chasm.
Early buy-in attitude
Break away from the pack
Stay with their colleagues
Motivated by future opportunities
Motivated by present problems
Seek what is possible
Pursue what is probable
Think pragmatists are pedestrians
Think visionaries are dangerous
The conclusion: pragmatists don’t trust visionaries as reference.
Geoffrey Moore’s studied the ones who successfully crossed the Chasm and made a single observation. The difference between the visionaries in the early market and the pragmatist in the mainstream is that visionaries are willing to bet “on what’s coming” and pragmatists want to see solutions “in production” before buying.
When a visionary sees that you have 80 percent of the solution to his problem, he says, “Great, let’s get started right away on building the other 20 percent together”. A pragmatist, on the other hand, says, “Wait a minute – aren’t you supposed to be the one improving my productivity? I’ll buy this thing when it’s done – not before.”
The pragmatists want a 100 percent solution to their problem – what’s called the whole product. In other words, to satisfy the pragmatist, you must obtain the minimum set of features, product and services necessary to gain his trust.
For those companies that didn’t cross the chasm, they addressed this problem by targeting four or five likely candidate segments visiting major customers and asking them what’s missing, and returning with a long “wish list” of requirements. These lists were reviewed by market people and engineers who would extract the broadly requested enhancements. These key requirements were to define the next release.
This way the next release came out and had something for everyone. Unfortunately it had everything for nobody. That is, not one customer ever got 100% of the requirements fulfilled. The pragmatists appreciated the efforts but wouldn’t buy the product. So release after release came but no one got the minimum set of features they needed to be convinced.
This leads to the strategy of crossing the chasm. You have to put all your eggs in one basket. The key to a winning strategy is to identify a single bridge of pragmatist customers in a mainstream market segment and stick to them until they are convinced. The goal is to win a niche foothold in the mainstream as quickly as possible and then expanding from niche to niche.
The niche shall be small enough that you quickly become the dominant player in that market segment. The target should be of a strategic value so you can invade other nearby segments after you have established yourself in the first target market.
Moore’s model is the D-day invasion of Normandy: once a strategic beachhead is taken, establish a starting point for other focused initiatives. If you don’t have a whole product, you partner up with another to get the whole product offering.
Summary of Technology Adoption Process and The Chasm Theory
Don’t end up with a product or system that has something for everyone but nothing for anyone. Instead, focus on one target and strategically important segment that is small enough to become a dominant player. Expand to nearby market segments from there. Here are the motivations, characteristics, and challenges of each phase.
Chasm Theory: Relationship to Software Development
Whether you’re developing a product or an internal system, you need to sell the idea to either the company or to an external customer. You must learn how to handle visionaries and pragmatists and change strategy when necessary. This knowledge becomes important to help software project to prioritize in with order a project shall be implemented and to with users and customers that the system will be introduced. When business development people or project managers interview different stakeholders they often get lists of a lot requirements and features that stakeholders wish the system/product shall have. If you take them most important features from all different stakeholders and don’t implement all for someone you will end up with a product or system that has something for everyone but isn’t valuable for anyone. It’s therefore important to see that the system got value for the first users and they are chosen wisely. They should be influential on other groups and stakeholders.
In a world with endless of opportunities and choices, you can’t run on every ball. A soccer game is 90 minutes and you get the lactic acid after four minutes if you run into any passes. Focus is about following a strategy and putting your resources on things you have deliberately chosen.
If you act on everything that comes up, you will soon forget your strategy, and all your effort will go to put out fires instead of creating things that will generate advantages in the future. Focus is how efficiently energy and direction are transformed into a result. There are a lot of different factors that affect how efficient the knowledge transformation process is performed. To focus means working with a single thing, instead of doing many things at the same time.
Serial Instead of Parallel Focus
Let’s say you spend 40 hours a week at work. We’ll call these 40 hours “Energy.” You have two projects that require your energy and you’re switching your energy between them. You will need knowledge (called Knowledge Quota) about both of these projects and you will have different stakeholders, so you need twice as many relationships (called Social Quota).
If you split your engagement equally, your projects will have 50% (5/10) of your energy, 50% % (5/10) of your knowledge quota attention and 50% % (5/10) of your social quota attention.
This means that your efficiency will be 5 * 5 * 5 = 125 points out of a maximum 1000 points per project. This gives you a total efficiency of 2 * 125 = 250 / 1000 ≈ 25% efficiency.
If you feel pressure to perform better, you raise your engagement in all parts by putting in 20% more hours, which means 10% extra on each project. This gives you a total output of 6 * 6 * 6 * 2 = 432 point’s ≈ 43%.
Consider this. If you just focused on one project, your maximal attention could perhaps be raised to 70%. Your base efficiency therefore would be 7 * 7 * 7 = 343 / 1000 ≈ 34% for that one project.
If you put maximal effort into this project and increase the effort on all levels by 20%, see what happens: 9 *9 * 9 = 729 / 1000 ≈ 73%.
Nowadays, a lot of different works are called projects. The nature of a project is to accomplish something specific within a specific period of time and that involves people who normally are performing other functions but are called upon to participate in the project. A project comes about when people form a new group to concentrate their efforts on reaching a specific goal.
A project therefore begins with situation (A) where two systems work fine independently of each other. Then you have a goal (B) whereby integrating these two systems will produce new possibilities. To clarify this, the goal is not to integrate the two systems; the actual goal is the value that is gained when new possibilities arise that would benefit the entire organization after the two systems are joined together.
What is Success?
You might think it strange that I wish to define success. After all, everyone knows what success is, and can readily identify successful people.
But I believe that the concept of success constitutes one of the foundations of this book. Before achieving greater success, I think it’s essential that success is defined in terms of managing a project. Based on my many years’ experience in software management and project management, I define success as: knowing that the value of reaching (B) is greater than the “present situation (A)” + “the journey”.
What is a Successful Project?
To establish that the value of reaching (B) is greater than the “present situation” + “the journey”, the team needed to do the right thing in the right way in an optimal way. This consists of at least 3 different roles.
First, the role of doing the right thing – this involves researching what activities and features could lead to the expected value (B).
Second, the role of doing it the right way – this involves producing the software so that it does the work it is supposed to do according to best practices in software development and based on the rules.
Third, the role of doing it an optimal way - this involves the planning and execution of the project to everyone’s satisfaction. The stakeholders, end users, as well as the development team should be satisfied with respect to both the short term and long term outcomes.
A sure way not get optimal results is to not work with others through the whole process. It could mean working with a company that can provide the knowledge or expertise which is what companies do when they don’t have in-house expertise. It could also mean working with individuals within the same company but who come from other departments and are called upon because they have a special skills that are relevant to the task.
Whatever the case, success can only be achieved if people work the entire process together. I have done projects where the customer company did a feasibility study and identified their needs and then procured the system. The agreement between the two companies was to regulate the project as they were afraid of losing advantage.
After the agreement was signed, we coded the system. What happened? At the acceptance test phase, there was plenty of feedback from the users. One feedback was we misinterpreted their requirements; another feedback was they realized they needed some extra features for the system.
A lot of mistakes were committed, but the main lesson of this story is to show that to be successful you need the right resources to do the right thing, because if you don’t build the right system, it won’t matter if it works great and is easy to maintain. To succeed in a software development project, you need the right business people who completely know the business and the process to be supported.
I have been involved in a lot of projects of this nature. Everyone in the software development team worked hard in building what we thought was a great system only to discover that users did not appreciate the great features and instead mentioned the lack of other features. It was depressing to work so hard and then realizing we didn’t meet the users’ expectations, because we didn’t get them involved right from the start.
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.
The difference between knowledge and creativity is that knowledge is known by others, and is accepted and understood better by a group. New ideas are the opposite of knowledge, neither known nor learned before. It is therefore, by nature, not accepted. So it has to be sold to others to create value. It doesn’t matter how many ideas you come up with; what matters is if you can sell those ideas to others.
Anchor the Idea
Your project, no matter how good, won’t matter if you can’t get anyone to buy it. It’s therefore essential that you can sell your ideas to others. To research an idea more formally, you might need to anchor it with someone who is in charge.
The first thing you have to have to deal with is the question, who will be in charge and who will gain from this? In the early phases of the process you probably won’t have any figures or analysis, so the first step is to convince those in charge of the strategy that you can do a feasibility study and investigate if the idea is worthwhile. Who should you convince?
If the idea targets new possibilities, that might give the business a new advantage. Contact people who work with the strategy and talk to sales people. They are the ones with this mindset.
What is the Effect Enabler?
A project idea is often born out of the company’s need to increase its results and competitiveness by creating a new service, product or approach (e.g. becoming more businesslike). It often comes from either the ability to do a new thing with the combination of features, locations, customer segment, promotions, better adaptations to a special process, increased efficiency, or saving money. It’s important to find out what the effect enablers would be for the customers – would they be new features or cost savings? This can be done by asking questions like:
Does this idea lead to higher profitability?
Does this lead to any new possibilities?
Does this lead to any efficiency or cost savings?
In this early phase it’s impossible to know something about the cost to make the journey. What you can do is try to sell on the value of (B). And if you can’t sell by agreeing that the value exceeds the cost through a cost analysis of the journey relative to the value of (B), and then you have to try to sell on emotion, and try to motivate the one in charge.
For example, you can ask “What does this idea result in? What are the benefits? What would we do if we had this already?” Salesmen use a common trick: they change the perspective of the buyer from being a buyer to being an owner. Instead of arguments like considering the costs, salesmen often argue about how much the buyer can save if he bought it, or what new possibilities would the buyer obtain if he owned it?
There are two reasons that determine if a project is an IT project or not. Projects aim to raise the return on invested capital; the two main enablers are to save money or raise the perceived customer value. Either you become more efficient or you get new opportunities. There is often a combination of these two where projects aim to both get new opportunities and save money at the same time. If the first priority is to get new opportunities and raising the perceived customer value the marketers will probably be your customers. And if the main enabler is saving money, you customer will probably be a administrative manager.
This knowledge that it either cost or new opportunity focus is important when you analyzing requirements and do privatizations. You might have a lot of different stakeholders and users that you need to interview and it might be hard to understand what they really wish to accomplish with a specific feature or demand. Then it can be helpful to think is this a cost saver or a new opportunity? And if you plan a project and come up with a plan you might surprised that you customer will be negative and worried if you after interviewing different stakeholders and users comes back with only features that enables new opportunities when the customer did expect cost saving features.
If you’re not enthusiastic about your own idea, it would be difficult to convince others to buy your idea. A person who is enthusiastic and realistic about something has an almost magical appeal. People are attracted to people who are enthusiastic and realistic because they feel those sentiments themselves. It’s hard not to get influenced by people who are cheerful about new ideas and life in general.
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?
If you’re not a future teller planning is guessing. Strategy is about continuously choosing what to lay your effort on. A soccer game is 90 minutes long and if you run on every ball you will get lactic after 4 minutes. So strategy is about letting you team know what to put their effort on, which situations that helps us with our long term goals, so the team members recognize situations where it’s worth the effort. They know when everyone else in the team will join in and help you and at the same time know there role in the game. Some are middle field players the help get the ball up and are pushing things up the forwards. It’s the same in projects not everyone talks everything from idea through development and deployment. If you don’t got a strategy people will not be able to recognize situations where the whole team will come together with the whole team effort. People will run be able to judge the value of a situation. Better planning, as Mary Poppendieck (author of “Lean Software Development”) points out, results in a higher standard of living for the individual, for the team, and for the organization.
For all stakeholders and team members to create a mutual understanding of the project’s direction and goals, it’s a good idea to document expectations and the means for meeting those expectations. This is called the project plan.
Depending on the type of project, the purpose of the project plan will differ. If it is a very formal project, it is primarily written for the project client or product owner. The degree of detail contained in the project plan will depend on how formal and plan-driven the customer is and to what extent he wants these details laid out.
The Plan is Worthless, Planning is Everything
Plans are great for complex projects because they set the direction and the alignment of goals. However, the value of the plan decreases over time. Is it realistic to plan all activities upfront? Projects live in a world of constant change and new insights are gained so planning on a detailed level for a six-month timeframe isn’t practical for software projects.
This is one of the foundations of agile methodologies. For the short term, when an overview is created, detailed planning is helpful. But for the long term, a plan is simply to set direction. Discoveries about the project will be made, you become wiser from gaining all that additional knowledge and you change priorities.
The parallel to sailing
I’m a passionate sailor. I have spent my vacations sailing since I was a child. Each morning we plan where to go and what to do. We use charts to see what to expect during the day and which milestones we can establish to make sure we’re on the right track (milestones). When we start sailing we don’t see our goal (destination) so we rely on our milestones and compass. On windy days the waves splash against our boat and the sea looks dramatic. Looking beyond the horizon, the water appears calm. Reaching our final destination is as dramatic as the enormous waves we encounter.
It’s the same with project plans. From a short-term perspective, you get an overview of the drama, but from a long-term perspective, you can only rely on your compass and milestones.
A common timeframe for detailed plans is 3 to 4 weeks. In Scrum, a common iteration is about 3 weeks’ worth of work. In the beginning of these three weeks, the sprint is planned in detail.
Projects are like sailing trips: changes occur often because of the need to adapt to changes in the temperature and oceanic conditions.
There are different ways to start planning the trip from A->B. It can be hard to cope with dependencies and the order in which things are done. A good step is to identify the whole work package in the beginning and then break it down one at a time. Brainstorming will facilitate project delivery. Another way is to start with the goal and go backwards. To deliver we need to submit our application to the AppStore at least 3 weeks before the “release date.” Another 2 weeks is required for testing and other related tasks.
Large and complex projects can be divided into smaller parts and be planned as single units. Milestones serve to monitor progress and allocate resources. A milestone should have a clear goal that is related to the project’s outcome. Milestones are essential in controlling projects. When combining activities with milestones you can make a critical path method, helping you to identify risks of schedule slip-ups if a milestone is missed.
Critical Path Method
Many projects fail to meet scheduled expectations because there is a timetable slip-up in an activity. The Critical Path Method is a technique that is used to predict total project duration and helps control project overruns. The method takes the different activities and relates them. The critical path can be identified, as well as identify the longest path where there are dependencies in relation to other activities (marked red in the diagram underneath). For effective control of activities, these are the ones to watch and monitor.
A person’s comfort zone is a type of mental condition in which a person is confident of the outcome, and that his behavior or situation will not create a sense of risk. When a person does something or finds himself in a situation that raises his anxiety level, that person’s prior experience tells him that it won’t work, or that he doesn’t know how the outcome will turn out. If a person never takes a risk or puts himself in a situation the outcome of which he is unsure of, chances are he will not gain any new experience. As a manager and expects you team members to grow and dare to leave their comfort zone you will have to do that to. You have to show them how to take calculated risks. If you don’t dare to take risks for the team, how can you expect them to take risks for you?
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.
The point of working together is because the sum of everyone’s work is superior than each individual work. More gets done in a shorter time. The point of working together is to bring together the different skills required for a complex project.
This blog post I will discusses group psychology, which is a field of study that can be valuable to leaders and managers. Software development is about cooperation between humans so this will be an an indispensable section of this book.
No group ever becomes a team until it holds itself accountable as a team.
“The wisdom of teams” by Jon R. Katzenbach
What is a Group?
A group is more than a bunch of people; they have common interests. A group consists of two or more people who are socially related. The more interaction there is within a group, the more influence members have on others, potentially leading to changes in their attitudes and behaviors. After working together, norms and values are developed within the group. There is something that distinguishes the group from others. Some call it team spirit, a group members could describe it like this group have specific norms and values. Let’s visualize two people (A and B) who have some kind of relation (C).
The more (A) and (B) add to the relation (C) the greater and more important the relationship (C) becomes. If both (A) and (B) think they deserve to get more from (C) than what they each contribute to it, the lesser the relationship (C) becomes.
A friend told me why he broke up with his girlfriend: “I didn’t get enough from the relationship, there was nothing left between us anymore so we had to break up!”. It’s when 1 + 1 equals more than 2 a