The need for something new

If you have worked in the consultant business or in a project based workplace you probably have felt the pain of flawed processes. The lack of structure or the confined structures strangling the project all tangled up with a confusion and uncertainty of what is actually expected. Communication issues between management and development teams make development strained at times and you need to work overtime or worse just to show the client or boss that you are taking damage control serious even if it will not solve the issues in the project.

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.