Archive for the ‘Chapter 4: The World Around the Project’ Category
November 27th, 2011
There is a different level of engagement among stakeholders. Some are really involved because their stakes are high and their risks are greater, while some are more interested in being informed. Scrum has a small story to show the difference between a stakeholder you really need to focus on and one who is not as involved.
A pig and a chicken walk down the road. The chicken says to the pig, “should we start a restaurant together?”
The pig answers, “What a great idea! What should we call it?”
“We can call it Egg and Bacon”, says the chicken.
“Hmm, I will be really involved putting my ass in the pan, but you will not be as committed when you are just laying eggs!”, answers the pig.
This is the difference between stakeholders with stakes and stakeholders who don’t.
When starting a new project invent everyone that might have expectations on the project. Then you can organize them after their interest and power over the project. This gives you a clue of you will need to manage that specific stakeholder so that you put your energy on the right ones. This helps you see identify key people not just the one that sounds much.
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. I want to point out that making everyone happy to a certain extent is a key role of the software development manager.
The Process of Managing Stakeholders
If a project manager’s main concern is to get all stakeholders satisfied lets analyze the flow of the work. Stakeholders have interests in the project and communicate their expectations, when all expectations are recorded a prioritization can be made based on strategy and stakeholders power. Because you got limited resources you will not be able to do everything that everyone wants so you will need to make a lot of trade-offs in order to get everyone committed and satisfied. The worst thing you can do is not to be clear that all expectations will not be fulfilled
Many companies just record expectations and write down requirement but never sit down and really prioritize what is important and really drives business value; therefore, it is common for developers working on features that are more of a decorative art and good to have stuff than real business value. This is not the developers mistake is the business and project managers’ mistake, programmers might implement a function perfect. It’s quite common to make the wrong thing in the right way.
August 14th, 2011
IT-strategy is how IT supports the business strategy. It aims to establish a business-driven approach to effectively dividing IT resources. This defines the expectations from IT and how limited resources are to be divided. To manage any software development project, the overall IT strategy must be clearly understood. It’s also important to understand how well the software development supports the business strategy.
This post will cover:
- IS/IT-strategy – what are the demands on IT and how will IT support the business strategy?
- Enterprise architecture – the roadmap of IT-systems for the organization.
- Architectural frameworks – tracing the business strategy to specific projects, applications and features.
Having a strategy for IS/IT covers what to do and what not to do with IT. If the strategy is not followed, you will indirectly not do the things you like to do in the strategy. The organization has limited resources and if they are to spend more money on things outside the strategy, chances are you will not be able to do the things you want to do.
IT-strategy summarizes some of the following:
- High level organization: How is the work organized? Who is responsible for what?
- Project portfolio management: an inventory of current and future projects managed by IT. Contains a description of the project’s objective and scope, timeline, and expected benefits or return on investment (ROI).
- Resource summary: how is the IT function staffed and how is budget allocated?
Like most strategies, a common tool is the SWOT-analysis which helps to organize what could and should be done and prioritized.
There are different strategies. Here are a few examples that show what’s expected of IT and what the outcome of a specific project aims to gain.
There are basically two different aspects that drive all IT investment. Either they are competent so the project is completed, or they gain some advantage over the competition. The advantages could be cost savings, reinforcement of the company’s USP, or both. The list below describes of IT investment:
- Basic business costs. Costs are necessary to be able to compete and continue the current strategy. Processes change and IT needs to follow.
- Extended business costs. These costs are incurred when companies develop new solutions required to organize the process.
- Differentiation. Strategic investments to gain an advantage. They could be a cost advantage or a different product or service.
- Next frontier (strategic). Funding new pilots to find new potential differentiators.
If an investment doesn’t fall into any of the planned strategies above it shouldn’t be done. If the companies develop a feature that is not part of the strategy, it may mean non-use of those features or activities. It’s therefore a risk to add features to an application or product that a developer happens to like or finds it easy to build while in the middle of that module. It’s tempting to say yes to small features that programmers recommend, but the # 1 question is, do they support the overall strategy? Time and funding are limited, and resources must be devoted to those aspects of the project that require them; otherwise this can lead to neglecting or not doing the essentials of the project.
IT-Strategy: as it Relates to your Software Project
This isn’t a book on IT-Strategy and how to organize it, but it’s important to establish a relationship between software projects and the overall direction of the organization. In an IT-Strategy, there is a larger plan for what the systems do and how they relate to each other, otherwise known as the enterprise architecture. The enterprise architecture describes how different systems support different business processes. To support IT-strategy, the enterprise architecture tries to address all stakeholders’ needs within the organization’s need.
An enterprise architecture tries to design an optimized roadmap relative to existing and future resources. Business is constantly changing. The roadmap must therefore be a priority to reflect these changes. This way, there’s no risk of sub-optimization. Sub-optimization, in the context of software development, may mean systems or projects that don’t duplicate functionalities. It can also mean solving the wrong problems, or introducing unnecessary complexities.
The relationship to software development!
It’s important to understand the context you’re working in. If you’re working in a larger company, there are different strategies for deploying technologies that are relevant for the future and technologies that should be depreciated. For example, if the company thinks that websphere and Java are the future, it might be a bad idea to use PHP. Do you think your system will be around for a long time or will it be discarded soon?
An architectural framework provides a formal and highly structured way of viewing and defining an organization. An architectural framework is not a methodology on how to organize the work in a process; it’s a classification structure to document enterprise architecture.
The most established architectural framework is the Zachman framework, which I haven’t worked with because I was schooled in the 2xSundblads framework. Given that the Zachman framework is the most established, I will use Zachman as the example in this book.
The Zachman Framework summarizes the perspectives involved in enterprise architecture. You can see the framework as a template that forces you to investigate various things from two perspectives. It consists of a two-dimensional classification matrix that forms a 36-cell table. On the rows you find different abstractions (scope, business model, system model, technology model, components, and working system) and on the columns you find six questions (What, Where, When, Why, Who and How).
The Zachman framework is a simple and logical tool to structure complex and evolving enterprises. There is no order of priority for the columns but the rows have a top-down order. The Framework takes into account both the artifact target (for example, stakeholders) and a particular issuer (for example, a specific system). I find that an architectural framework is a great way to organize things when it’s really complex and you don’t know where to start.
Summarizing the IT-Strategy
When organizing a software development project it’s important to take the context into account and how your work is related to the overall business strategy. If the project isn’t aligned with the organization’s strategy the project will never be successful.
The bigger a company becomes, the more complex the business processes will be and hence a larger need for proper coordination. The point is to be successful, it’s important to understand what the effect enablers for the project are. If you don’t have a customer who is clearly responsible for that, you need to address this yourself. You need to connect the overall business strategy to the project’s goals and to ensure that the value of the outcome is greater than the effort. Addressing the business perspective is indispensable.
May 27th, 2011
Higher management staff – CEOs, CFOs – CIOs – Business Development – are normally more interested in how products and services reduce cost, generate new revenues, strengthen the trademark and brand, improve customer relations, create new market positions, and acquire competitive advantage. They regard their respective departments as unique and special, so out of the box solutions would probably not be welcome.
Higher management individuals work at a strategic level and their decisions are seldom short-term. It’s therefore important to show them clearly how the solution will support the business. Why should they invest in this? Their perceptions are influenced by those they serve and the costs of providing this service.
Middle management staff – product or system owners, line managers, administrative managers, software development managers and business development managers, ), focus on what their respective business unit does. They are often focus on a specific project or responsibility making sure that the proper “housekeeping” is done so everyone else can work efficient.
They work at a tactical level and prioritize different activities. Their main preoccupation is how to make things more efficient. They do comparisons and benchmarking. Their perceived customer quality is based on the ratio between prices in relation to the perceived value. They are responsible for their assessments of new systems and features.
It is therefore essential to demonstrate to them why the solution or feature they require is produced with cost efficiency in mind and which would be the best solution for them. The keyword for middle management is what. What does the solution, system or service do in particular that it cannot be obtained at a cheaper price elsewhere?
The competitive factor is not price, but the perceived value that can be obtained. They like to know that what they like to achieve is clearly understood. Documenting their requirements is one way to prove that their needs are understood.
Team and Operations Management
Management at the operations level is often very close to execution with good insights about the process. They know how work is performed. They are more interested in how things are done and how they should work with a specific solution. Business value is easier to measure in terms of work and costs. The interest is on the details of the solution. At the operations level, the right competence for the right task is what matters most.
March 26th, 2011
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.
Crossing the Chasm
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.
March 23rd, 2011
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.
March 21st, 2011
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.