Archive for August, 2011

Accept Complexity and be Free of Guilt

Comments Off on Accept Complexity and be Free of Guilt

“You are in the undiscovered land now, no one expects you to know what behind the next rock!”


Realize that we’re all seeking simple truth where there aren’t any. By accepting that you work in a complex situation you let go of the presumption that you can predict things. If project steering groups demand predictability they will get a plan, but they will get a false sense of control because complexity can’t be predicted. This only created guilt for the project manager in charge and then down to the team, when people are expected to commit to a non-deterministic process.

What is IT-strategy about?

1 Comment »

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.

Role of it

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.

Aims for

Enterprise Architecture

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.

Enterprice architeture

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?

Architectural Frameworks

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

Zackmans framework

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.

Time Estimation

Comments Off on Time Estimation

How large portions of the work should be estimated

In software development, it is difficult to understand the complexity of a project.  It is therefore a good idea to split up the task in smaller parts where the largest part will take less than 40 hours. Large and complex chunks of work need to be split in smaller parts.  My observation in time estimation is that complex tasks seem to be 90% done and stay that way much longer than tasks that are less complex. This is the consequence of undertaking an endeavor in which you have no experience

I will present two methods that I use, both separately and together. We have used planning poker to estimate the most likely value and Lichtenberg to handle the variations.

Planning Poker

Planning poker is a consensus-based estimation technique. The method was first described by James Grenning but it gained popularity when Mike Cohn wrote the book Agile estimating and planning.

Planning Poker

When an estimation session is done, one person describes the requirements for the group. The group discusses and specifies how to fill the requirements. Each participant makes an individual estimate but does not say it.  They use playing cards with pre-set numbers. The denominators are 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 and “Don’t know”. The values can be in either hours, days, ideal days or story points.

When everyone has played their card, the card is shown and the group discusses the estimates with those who provided estimates that were radically different from the rest.  After discussion notes are written (which might be valuable for future development) a new estimation is done. This time the estimates are more similar. If this doesn’t happen, the process is repeated. It is not necessary for the whole group to have the same number because the objective is a qualifying assessment rather than a precise time period.

Lichtenberg’s Method

Professor Steen Lichtenberg developed a mathematical method to estimate time which also provides a measure of uncertainty in addition to an assessment of the likely value. Minimum and maximum values specify the limits of uncertainty. These dimensions should be such that there is more than a 1% probability that the actual result will fall outside the min-max range. The estimates are based on certain conditions, stated or unstated, such as who should do the job. The uncertainty is processed only on those parts which are most important for the project’s total uncertainty. Because there are so many project unknowns, the min-max range will be large. The project’s end date and total cost are not stated, only a probability assessment is made.

Lichtenberg method

When doing an estimate, specific activities are discussed with a view defining what is included and how it was and will be done.  The group tries to estimate how long it will take one of the members to achieve it. This is done by the person or persons who will be doing the activity later.

When the most likely value has been agreed upon, the group estimates how long it will take to do this if everything works out great. Then the group discusses the worst case and estimates the difficulty level of the activity. When estimates of the “most likely” value, “best case” value and “worst case” value are obtained, the following formula is used to calculate the expected value.


This calculates the probability that the team will be within a 95% interval with the following formula.

So let’s look at an example.

Lictenberg Example

Project Manager = The Man in the Middle

Comments Off on Project Manager = The Man in the Middle

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 Man in the middle