Yesterday evening, my new Whitebook about Agile Enterprise Architecture (see here, in Dutch) got published. In this Whitebook I pointed out that developing Enterprise Architecture is a Two Way process. And that it should be build Agile.

First of all, a Business Case should be leading in the choices that are made in the architecture. This is, simply, because we look at architecture from a project point of view. A project start architecture needs to be the beginning of a project, but measured against the organization. This is exactly the problem I encounter on a near daily basis: Enterprise Architecture made too big and becoming an ideal picture instead of an realistic and facilitating process.

Enterprise Architecture basically needs to describe the Business processes, the information demand, the applications overview and the technical grounds. This is the blueprint on which we can build our system. But how can we make sure we don’t overdo it? Simple: make it Agile.

Agile Enterprise Architecture works on the same principles as Agile Software Development: the Agile Manifesto. When we understand these principles, building an architecture for our project and organization is made a lot simpler: look at the stuff we actually need right now, don’t over document the process and let people be the basis of knowledge.

In other words: Agile Enterprise Architecture is a Two Way process in which the entire group of stakeholders is leading. Therefore it starts with the basics: why do we need it. (and what don’t we need, eliminating waste.) In Agile Enterprise Architecture there is room to learn and adjust, because we don’t do everything at once, but listen to what all stakeholders have to say: what can IT learn from Business, and the other way around.

The principles of Agile Software Development are known to most of us, but how we put them into action can be the tough challenge. At the second session I had on CreativITy at the Fontys school for Software Engineering in Venlo we discussed the possibilities to make Value the steering point within the project.

After a short recap on the previous session we started off with the dilemma we encounter in IT these days, talking about the classic Cost versus Risk model on which we use to steer our projects and where the money goes doesn’t work, value isn’t measured. Using the new insights in Agile development and Enterprise Architecture, value is one of the key points: where will the business benefit most.

During the last part of the session we discussed the new possibilities technology can offer to business values these days. How can we switch from servicing to innovation? Agile thinking sure helps here.

“Fear and Complexity within a project, can be an explosive mixture that makes sure any project can fail.” According to the experienced agile project manager Martin van Borselaer Fear and Complexity are the main project killers. “Fear restrains us from doing or saying the things we know are right”, Martin says during a great session he gave the company last week. “It is, in combination with complexity, the main reason projects fail.”

Fear, from the different actors within the project, can have different sources. The customer can be afraid that the project will cost too much, the quality will be bad or that he works with the wrong requirements. The supplier has it’s own fears. Under budgeting the project, dissatisfied clients, damage to his reputation or unsatisfied co-workers. A project manager can have fears like a bad functioning customer organization, team or technology he has to work with. And the team member is possibly afraid that the balance between his private live and job comes into question.

“There are also deeper fears to consider within a project” Martin tells, “you can think about things like the livelihood of the employee, loosing his job, not making promotion”. ”Or more emotionally based fears like the ego or status of actors in the project” Martin explains. “Fear is a very bad advisor in a project situation. It can offer a excessive reaction by making problems larger than they really are, or no reaction at all by denying the existence of a problem.”

In projects this can mean that we work with fixed date, price unknown scope projects, excessive analysis and design or not being able to grasp reality and therefore sticking to the original plans without necessary adjustments. Martin explains that most of these examples are based upon actors being afraid, offering false hope. Working together, not looking at the team in terms of heroes and losers, is an essential part of the solution. Transparency in the project team will facilitate mutual trust and therefore a real team where fears can be tackled.

Another project killer is complexity. “Simple is Stupid and Smart Sells are main criteria these days in IT projects. Or, at least, it seems to look that way” Martin says. “The assumption lives that we can control and predict this complexity, but the reality is that we can’t.” Martin explains that, during the start of a project we don’t know what we want and that we don’t know how to get there. Working together and steering on new insights is the only way of getting on a point where we want to be.

Working together, small steps and learning and improving are essentials to tackle both fear and complexity within a project. Organizations that know that change is to be expected and understand that steering constantly is normal will have the competitive edge. It’s essential that scope is put together on functionality, not by expertise. Bringing together expertises will reduce fear and complexity. Or at least make them more understandable. In this way we can actually manage them.

Martin van Borselaers blog is a very interesting place of knowledge on Agile project management, you should read it.

UPDATE: Martin now offers a once in a lifetime opportunity: you can get his advise, for one day, for free! So if you want to have a fresh look at this project of yours or more information on how you can do things different or even better, look on the (Dutch) Whitehorses website for more information.

At this very moment I’m waiting to give one of my lectures at Fontys Hogeschool on Venlo. A long drive, so I got here early. One of the things I’m going to talk about are the missteps in Software Development, and project especially. One of these missteps is that we tend to think that we need to Predict, Guard and Control our projects in order to make them successful, while this is exactly why things go wrong.

In the classic approach to software development, we like to think that there’s unforeseeable risk involved. That we need to predict the outcome of the project and guard that change is not an issue. In this approach, using extensive Architecture, Analysis & Design and Processes like Request for Change using boards and advisories. Why is this? Do we have so little fate in our own skills?

When we take a look at what we actually are doing in a project, predicting, guarding and controlling is very strange. Because we are trying to make ideas, thoughts and vision concrete. We build stuff that on forehand only exists in the mind of some.

Thoughts and vision change during time. We gain new insights and other people share their knowledge. This is exactly why software development projects need to be based on a change facilitating manner, not trying to avoid change, or make it more difficult.

Software Projects don’t have a great success factor. According to some, this is because projects are too big, not measured right or simply didn’t have the right steer on it. These factors can all be true. But there’s more to it. Maybe even simpler. Most successful projects have been seen like a success from the moment they started. It was predefined, they where steered with one thing, vision.

But what is this thing we call vision? And more specific: what is it in a software project? A vision isn’t just one thing, it’s two: the Why ad How of your project, shared throughout the entire project team.

The six basic questions: We’ve mentioned them before. The six basic questions in analysis are essential to know where the vision may be found. The answers to those questions can, however, be different for all the actors (and therefor factors) in the project, it can only become a vision when the answer are, somehow, aligned to each other, when the entire team and all actors share the same motivation on the project.

SIx degrees of Why: This motivation of the project can be specified by simply asking ‘why?’ six times after. This sounds more simple than it is. Simply start by asking why a project is necessary, why we are doing the project. If the answer is unsatisfactory, keep asking it. If a project has a clear vision, six degrees aren’t hard. But if the project has it’s soul ‘Why’ on ‘Because’, it’s a clear sign that there it no emotional attachment to the project.

The essence of How: in the end, Software Projects need to address the Why. It’s that simple. If the technology, design or any other aspect of the ‘How’ are not clear, the success rate will be at least as bunkers as when the ‘Why’ isn’t clear.

Emotional Attachment: both the Why and How need to be emotionally attached to all actors in the project. For the Why it means that we need to search for something that all parts of our team can feel in their guts, something that makes us tick, shake and rumble. This can be something that needs to be addressed because it affects us all or something so wild, we simply want it. In the How part it’s simpler: make it cool, awesome, jaw dropping. In software development we all like to be part of something amazing.

All the above have a certain ‘vagueness’ over it. This is because it is. It’s as simple as that.

Do you have an example of a project that became a great success because both the Why and the How where shared throughout the entire team?

IT solutions can’t be measured, or at least, it’s hard. Not my statement, but something I hear very frequently. This is, by default, not the problem we’re facing here. It’s the logical outcome of looking at the different things. We should not be focusing on measuring the outcome of the IT project, the thing we need to measure is the value gained by it. In other words, the problem. Some very relevant terms come to mind, ROI, TCO etcetera, but how do we keep focus on these element during our project? And how to steer on them?

Money is one of the simplest ways to manage a project. Because it’s such a universal language. The problem here, however, is that it’s pretty tough to measure the preferred outcome when we’re looking at the solution we’re building. But this is (for the ones who know me longer than today) a completely wrong way of looking at projects in the first place.

In IT projects we’re building a solution to a business problem, or a business challenge for that matter. These are always measurable. (In other words, if this is not the case, we probable don’t have a problem after all and we’re done.) The measurement can be pretty complex, but certainly not impossible. Look at a few variables, including labor costs, estimated loss of business, transport costs, maintenance and management. The costs are, however, always part of the problem we trying to solve.

And here forth comes value. Value, within Software Development projects, can be the only real measurable. Looking at return on invest, ROI, this is what we’re trying to do. Costs and Value can be checked off during the project and the ROI can be a good measurement for choices that need to be made.

In the book “The IT Payoff: Measuring the Business Value of Information Technology Investments” that Sarv Devaraj and Rajiv Kohli wrote in 2002, there’s a complete step-by-step methodology to assess the value of IT investments. This book lays out the basics for the modern information analysis and CIO / CTO. Devaraj and Kohli work on a basic assumption (which I believe to be correct) that the technological decisions are not in the IT department, but a joined effort and therefore joined responsibility.

When steered on value, IT projects can become much more clear where decisions are made and what type of effort is needed in order to make it a success in the organization. This also means that we actually can start making projects smaller and more efficient, because we own and share the insight where the largest profits are to be gained.

Looking at Software Development projects and the strategic implementation of this into any organization, we have to take three pillars into account. Technology, Policy & Management and Analysis & Design. All these aspects can make sure the build software will have an sustainable character and really adds value to the organization. But where do we need to keep our focus on?

Technology. The Technology pillar is the start of it all. Where Technology can actually add extra value to the organization and create a climate of support to additional demands and wishes for the business. Technology, however, can never be leading within the development department, business processes and their value have to be. Within an IT department that works very closely to the rest of the business technology can become a ‘driver’. Thriving the enterprise because of the possibilities the technology offers, this is a main role for the IT department and the responsibility becomes clear; work together. Technology strategy will focus on maximum results, with a minimum of effort, with the assumption to create a sustainable environment where business can keep focus on what they actually need to be doing and IT helps the business to meet objectives.

Policy & Management. Any IT project has to be managed and has a strategic policy attached to it. In order to define the policy concerning Software and IT Projects, we need to visualise the objectives, challenges and difficulties the Business we’re in are facing. The policy simply has to be clear and simple, no need to make thing more complicated than they need to be. Policy and Management are the direct results of business vision and therefore not in the IT domain. But it’s teamwork between the IT department and business.

Analysis & Design. To determine the value within the project and in order to make sure we grasp and deliver this value to the business at the end of the project, we have Analysis and Design. During Analysis we look at ways the policy can be matched to new business objectives and (or) business challenges (ne need to talk problems here). At the Design stage, not necessarily in this sequence, we determine how the Technology can support the policy. Analysis and Design are the main translations of the Policy & Management boundaries, mapped to Technology, to the challenges the Business has at this point.

Policy and Management are the layers we build upon, Technology and Analysis & Design are derivatives of the policy and the way we decide to manage the projects. Analysis & Design are, however, direct results of the made policies and the strategic choices we made on Technology. Strategic choices on the three pillars we mentioned above are measured continuous on Cost, Risk, Quality and Agility.

The coming period I will discuss these pillars, and the way we achieve them, with you and various others. Here on Ome-B.nl there will be more structure on topics related to these challenges. Or, how can we come to a customized and tailor-fitted strategy on Software Development?

Note: The image above is a detail on the Oracle logo, but Strategy doesn’t necessarily need to include Oracle’s Technology Stack…

Electrify! Not always a good thing, but in many projects, it might just be what the doctor has ordered. A lot of projects are just too long when it comes to really make people enthusiastic about it. So, what will make the project go ‘bang’, just the way we want it?

Add young people. This is, as many eighties series show us, a very simple action. ‘Young dogs’ in our project can give a lot of energy to the people already in it. Let the older and more experienced persons show off their skills and can give some fresh new insights in ways of designing and developing. It can take the tunnel-vision away.

Shorter iterations. Of course, obvious. But when faced with some dreadful deadlines, even the most dull project can regain new energies. Deadlines are there to keep, so everyone needs to step up.

The bell. Not always, in all teams a success, but sometimes ringing a bell can make people a bit more competitive. This can be achieved in more than one way. Not only ringing a centralised bell in the middle of the development room when a user story is finished, but think about other means. Like winning a dinner with your girlfriend when you’re the first to finish in a sprint cycle.

Are there any more way’s you can come up with to electrify the project-team? Any idea will do, nothing is too weird!

Within IT, and the rest of the world for that matter, we tend to think in orders of cost. How much money, effort, or any other measurable amount will something cost us. There are a few problems with that. First of all, within large companies and governments we’re not talking to the budget owner. Second, the people that might be the budget owner, don’t have to pay for it themselves (besides the very rare occasion where you’re talking to the owner of the company, or a partner). Third, money, in this context, doesn’t mean much, it’s like air. Within projects we always have a budget, but it’s not always fixed.

There’s a pretty easy way of making users, project actors or budget owners aware of money within your project. Don’t ask them how much it will cost, it’s a ‘non-question’. Instead, ask them how much it’s worth to them. You can do this over the entire project, to examine the value within the project. But also on particular features or specifications.

One of the lovely things about Scrum, is that we don’t have to ask these questions. We simply add parts of functionality on the board as user stories, and ask the project owner to make a selection from these stories for a sprint. Simple, isn’t it.

But during analysis and design of any software system there’s always this simple question: ‘What’s it Worth?’.

I know, tough one. When we take a look at Enterprise Architecture we tend to think of it as a fast and enormous endeavour. An extensive part of IT that only belongs in large organisations and within the service management organisation, not the project. At least, this is what I used to think about it.

When we take a look at Agile projects, architecture is a largely misunderstood element. This is, because we tend to think off it as the infrastructure our systems are build upon, but EA is so much more than that. We need three things: the technical architecture (the architecture part we used to look at, the infrastructure etcetera), the business architecture (derived from the business processes and the demands and wishes / requirements the architecture needs to be build upon) and the information architecture (the functionality and data within the architecture).

This doesn’t need to be an extensive document that takes months to complete. No, it’s a starting point, a continuous element within our project. Business architecture, for instance, is the definition of the business processes that are within the scope of our project, a description of the organisation and the derived actors within our project, the information architecture is the data, the distribution of data and the functionality. E.G. our user stories fit in perfectly.

In any project, even greatly steered Agile projects, there’s a beginning. A point where we need to define what we need to be doing in our project. Some call it iteration zero, some just start blank and put it into the first iteration, but we need to define the Enterprise Architecture (or better said, the project architecture) somewhere, in the beginning of the project.

Do you have an example of this? Where EA helped the project’s insights instead of putting unnecessary weight on the project.