This book is an attempt to describe a process that I believe works for large and complex IT projects as this is where I have my experience. This is also where I see that other ways of working fail most.

The result as I see it is that projects become more costly and that the people in the project will need to work more than necessary causing stress and sickness in projects that are either too rigid or to lose and a middle ground is needed.

In this book I will describe the problem as I see it with the various Agile and Waterfall methodologies. I will describe  the process that I use in my projects with the ideas behind each phase. The aim is to give you an understanding of how this process works and why so you can use it, in full or parts of it, in your own projects.

Before you start implementing what you find in this book however I want you to take this to heart: This is not a bible or a one size fit all solution that will solve all your problems. Implementing a work process or methodology is not something to take lightly because it has real life implication on people's health. This is why you should base the way you work on the people, not the process or methodology that happen to be cool at the moment.

If you see that the people need something else than what is being described here, then you should make the change for them. If you keep the basic need in the chain intact, then you can make changes without disrupting things in other parts of it. People a far more important in any situation so make sure you have their best in mind when you implement work processes and methodologies.

I have been in projects sold as fixed price with fixed delivery without even a shred of estimations being made. I have been in projects where the lack of planning was ignored with the mantra that it was ”Agile”, when in fact it was an Ad-Hoc project where scope creep was running rampant. I have been in projects so locked down that no flexibility was possible and the end result was a product that was utter crap.

This is when I realized that the only way to avoid this was to take control over the projects myself. As a project manager I got the influence I needed to find a way to work that actually work for everyone. I could take my experience as visual designer, UX designer, tester, developer and business analyst and look at the problem from multiple levels to see what can we do about the problems that we all experience.

I talked with the people around me and people I knew had great experience and discussed at great length about how we want to work and how we actually work. From that I could see that many of the problems and wishes other people in many organizations had been the same as I had.

There was clearly a need for a new and better method.

Over the years I have worked with large multinational companies and small local companies, and they all have the same issues. There is a fundamental lack of basic work processes and to solve this issue management cling to whatever the latest methodology flavor of the month is. They then try to force this down in the organization without understanding that change management is nothing that happen natural, or the fact that work processes should be defined and designed from both ends.

By this I mean that you have two main processes: the Business process and the IT process. These are not the same and while it is great to build the business process from a top-down perspective, that is a terrible idea for the IT process where you need a bottoms-up approach. Roughly in the middle you will find the most overlooked and misunderstood part of the organization: the requirements. The glue or the translator that ensures that the worlds of business and IT understand each other.

In order to fill these gaps that exist in many companies on how a basic work process work I have designed and discussed the different phases and their activities for many years. The work process I describe in this book is the result of those findings and it can be applied regardless of what methodology you prefer. The basics are there no matter what you call it.

I hope you will find it useful.

This means that what is defined in a requirement is what both parties agree should be built. This is rarely the way requirements are written and in many cases it becomes a wishlist from the business side instead of a defined agreement of what is to be built. Even more rare is it to get a definition of the business value of what is to be built and the thoughts behind it.

For a requirement to be efficient it is broken down into three parts: Business Need, Technical Clarification and Acceptance Verification. This breakdown is done to avoid the process of working towards failure. Working towards failure happen when all parts of the process work from the pre-conception that each step will fail in some way. This is common in misused Agile processes where the actual agile process is replaced with an ad-hoc approach.

To avoid working towards failure the requirement process need to have a proper handover process. This is because the requirement is not just a legal agreement, it is also a translation of the business need so it can be implemented. If the requirement is not properly defined to achieve that goal and handover should not be possible. This is why collaboration and a transference of ownership of a requirement is crucial for a successful project.