Search the Community

If you do not have portfolio management then your organization will suffer. There is no way around that because at the end of the day you will need a way to steer the organization based on finance and resources. It is that simple. Without portfolio management you will find yourself trying to implement processes to force control downwards in the organization. You will implement processes where people will need to report progress and different forums to "align" different aspects of the organization. At the end of the day however there will always be things you are unaware of and the cycle of control continue until your whole organization spend more time working with PowerPoints and Excel sheets. You will hire managers to get the information flowing, and they in turn will hire more managers. Soon you will have several layers of managers between you and the people you are responsible for and you will feel detached. This again will feed the need to control and so the spiral continue in an endless loop. I refer to this as a Low Trust Proxy Organization, or LTP Organization. This is the kind of organization where people are constantly stressed and you spend endless time in meetings just to have information flowing. This feed mistrust downwards in the organization so you will have project leaders and team leads focusing on control instead of clarity, making people feel mistrusted, uncertain and confused. The way to break this is to build up the portfolio management capability in the organization so you can get real time data throughout the whole organization. This way you have full control over resources and finance so instead of spending most of your time gathering information you can focus on solving issues that happen, when they happen. With a scaled portfolio management you can have any number of portfolios at different levels with focused information that is useful for just that level. By having this real time overview there is no longer any need for several layers of managers to feed the information through the organization. There will be less need to have meetings to "align" things and as you can see everything that happen from the inception of an idea all the way to release and the maintenance that follow, the need for control will be reduced. You will have a more direct path to the teams and you will feel involved instead of detached. I refer to this as a High Trust Direct Organization, or HTD organization.

If you plan to implement new ways of working based on this book, then it is important that you understand that change comes with a price tag. I have seen many companies embrace a new way of working only to place the burden of change on the organization. Nonsense catchphrases like "grassroot movement" or "crowd sourced roll out" are usually mixed with ideas like "teach the teachers" and "organic change". These are sure ways to fail to make any substantial change in the organization. Change must come from the top and you need to have a project for implementing change. This is because change takes time. By that I mean that time is taken from the teams when they learn the new ways of working. This means that the teams must have means to reduce their productivity during the implementation of the new ways of working. This is nothing you do in a couple of weeks and once you begin the implementation you need a maintenance organization for continuously work on the change. This is so the organization does not slip into old ways because they are not as fast in the new way yet, but also to teach new employees or contractors. The bane of any work process is fragmentation so you need to oversee when changes happen so you can bring people back to the defined work process, or update the work process when a better way have been found.

In this book I will refer to a few tools that I use to set up this work process. You can of course apply this process to any tool, but I have selected the most common tools that I work with that I feel work well for this purpose.

When it comes to defining workflows I see a lot of people making the mistake to build state diagrams instead of workflows. Since teams and projects tend to have very different ways, or thoughts on how to work, this usually lead to fragmentation and an exponential increase in statuses, resolutions and custom fields. So instead of focusing on every single state you have in a workflow in a long line, think of workflows as two dimensions. On the horizontal axis you move responsibility down the line towards completion. On the vertical axis you place the checklist, using subtasks, on what needs to be done in each area of responsibility. --Insert image of axis here -- I refer to the items that move along the horizontal axis as transitional items. The most commonly used issue type for this is the User Story. The items on the vertical axis I refer to as the producing items and those are the subtasks that is added when needed. By making this distinction we can define the workflows based on the transitional items as they move between the areas of responsibility. -- Insert image of AOR here -- In order to make things easy for the Jira users I usually design workflows with the fetch and release principle in mind. Not only will it make things clear on what is waiting to be worked on and what is in progress for each area of responsibility, it also makes it possible to measure those things, for KPI's for example. So in my designs I add status pairs for each area of responsibility, one waiting status and one active. -- insert image of fetch and release here -- When people design workflows they are often driven by adding control to the workflow. This is done by setting hard connections (transitions) between statuses. The benefit of this is that you will have fewer options if you use the drop list in the issue view. The downside is that it is often hard to see what is connected to what and you usually need to step through several statuses to reach the desired status. This is annoying when working in boards and it forces a defined setup of AOR's that may not be applicable for each team. For example a team can have an external team doing tests or acceptance, which would force someone in the team to move statuses across those statuses even though they are not involved in those steps. So to make the workflows flexible and still maintain structure we design the workflow with open transitions. That means that we add the allow all transition to all statuses. This will allow the teams to define their columns in their boards as they see fit based on their AOR situation. One thing to remember when you make an open workflow is that you need to add a post function to remove resolution for all transitions except for Closed. Lastly we and all workflows with just one closed status. I know a lot of people use the resolved status, but since that is simply an artificial status to ask for acceptance we instead add acceptance as an AOR. This makes Resolved redundant so we can remove it and by doing that we also avoid the "done, but not done" syndrome. Based on your issue types you may need several workflows, but I have found that you usually only need three for the build process. One for Tasks that follow the new->in progress->closed flow with supporting status for blocked/pending One basic development flow with AOR for development, test and acceptance. One extended development flow where the basic flow get Triage and Rejected for defect and incident management. The Task Workflow The Basic development Workflow (with code review) The extended workflow for Defect and Incident Management

When it comes to access and security, every setup have its own requirements. There are some guidelines I think is important however and one of them is to make the Jira Admins less dependent on external management. By this I mean that you should consider moving as much as possible into roles when it comes to access management. This way you will not only empower the Jira Admins so they can manage who can and can not do things in the Jira Project they are in charge of, you will also shift the responsibility of access to them as well. One of the big issues I see in many Jira installations is that there are often a very long chain to gain access, especially in setups using any form of AD. While waiting periods to gain access is annoying, the big issue comes by the fact that since no one really is responsible for the access, you often have a lot of people that should not be there anymore. The off boarding process rarely exist in these setups and that is not just a problem from a security and access perspective, it also clutter up the database with old projects, old fields and of course old users. So what we do in Jira is that we define a permission scheme that is based on roles. I tend to define this in three levels, but you might need different levels depending on your setup. Jira Admin (Role) - This role get full access to all functions. Project Member (Role) - This role get full access except for: Administer Projects Delete all comments Edit all comments Delete all attachments Delete all worklogs Watcher (Application Access or Role) - Depending on your setup you either connect this to all logged-in users, or a project role. Watchers get permissions to view projects and to comment only. The idea behind the watcher level is to allow people that may not have a direct role in the team to still be able to see and comment on things. This is useful for stakeholders and in some cases for product owners as well. The reason we do not give them Project Member access is that we want to avoid that people outside the team start to assign or create new things as that causes a big mess. Normally I suggest connecting the watcher level to application access so it is automatic and it allows for free roam across project borders. Not everyone is comfortable with that however, or need a more closed down setup for various reasons. In those cases you instead connect this to a project role. This will allow the Jira Project Admin to manage the access manually for more control. On top of this we add Site-Admins that of course get full access as well tied to their group. This is so they can do their jobs to administrate and help all users in Jira.

User Story Mapping is an excellent way to identify and visualize a skeleton of a software. A User Story Map is basically a customer journey that is used to define functionality in a system. Because this comes from a user perspective it becomes easy for management and business analysts to understand and map out the need they want to see in the system. As such a User Story Map is an excellent tool for business analysis, but it is not suited for requirements because it is focusing on what is visible only to the user. For development as actual user stories to build code towards a User Story Map makes little sense since most backend work is impossible to map in such a way and other development may affect multiple steps in the journey. User Story Mapping also works poorly for development without UI or with very limited UI's as it becomes more of an integration, or system mapping that should already exist as an architectural documentation anyway. Microservices and IoT for example have less benefit from a User Story Map while e-commerce sites and mobile apps benefit greatly. In any solution you are likely to have multiple customer journeys, which also means that you are likely to have multiple User Story Maps. This makes it a little complicated unless you are used to customer journeys, but there are great benefits from having customer journeys and user story maps for product owners and business analysts. This should greatly help define demands and need that they want to see as well as support breaking down those needs into features. Not all need will be possible to map properly however so there might be occasions where you will need to map need across the entire map. This can be for example non-functional requirements such as legal or performance related things. It can also be security or member functions that will span across the solution. This can be done by adding a generic lane above or below the standard journey steps.

I often see organizations trying to have one approach throughout the organization. It is either based on value streams or it is based on system organization. Neither work very well as a one solution fits all for different reasons. As organizations grow we see larger gaps between management and IT. This increase the need for control and this is why we see more organizations trying to force a value based organization today. You can read more about this in the chapter "The lack of Portfolio management reduce Trust" in the Portfolio Management section of this book. Value Based Organization Value streams makes sense from a financial perspective because value is one of the outcomes from the Iron Triangle (cost, time and scope). It is similar to the project based organization in that it has the financial steering as focus. Value streams aim to optimize financial output to create the most value for each investment. This is done by placing all involved resources and scope into one organization, meaning that you essentially split the organization based on value creation. Go over this section and expand it further. Benefits from this include: Usually fit well with the company organization that is often based on value or product Easy cost/benefit control when everyone is in one organization. Easier to manage communication and steering. Fewer dependencies Faster decisions due to fewer dependencies There are some drawbacks as well: Poor cross collaboration as the team work mostly independently of other groups Poor cross communication as the team work mostly independently of other groups Increased complexity of work as multiple value streams can touch the same systems Fragmentation of work processes is common as the team work mostly independently of other groups Increased complexity to maintain system quality and overview Duplication of roles as each value stream will have their own roles for quality and steering System based organization In this book I define the word system as any entity with a single source code used in software development. In essence every master branch is defined as a system by this definition. The system based organization makes most sense from a quality and competence perspective. This has been a common way to organize IT for many, many years as it is the most logical way to organize to ensure quality and competence. It makes sense from a delivery perspective to make sure you have the right people, with the right competence working on the systems they know best. It also makes sense to have documentation in one location for every system and one person in charge of the system from an architecture and quality perspective. Go over this section and expand it further. The benefits from having a system based organization includes: One source of truth for each system when it comes to documentation A focused team with the best competence focused on the system they know best A focused responsibility for the quality of the system The drawbacks for this are: Difficult to manage financially when value is created over multiple systems Difficult to collaborate from a value perspective when systems are isolated entities Difficult to communicate from a value perspective when systems are isolated entities Increased complexity to manage business need over multiple systems What is the solution? As both of these organization forms have their benefits and drawbacks. What we want from the organization is the best from both: The ability to organize and follow up based on value from management and the ability to focus competence and quality for IT. So rather than compromise by choosing one group over the other we use both. We use a value based organization on the management side, and we use a system based organization on the IT side. Then how would this work 4Real? We already have this defined in several frameworks like SAFe, even if they do not really spell it out as such. In SAFe it is called a cross-functional agile team, which in reality is a fancy way to say that the value stream dedicate resources from the systems to help facilitate value. The resource or resources will still belong to the system organization, but is dedicated to a value based organization as well. You can compare this with how consultants work. Each consultant is employed by one company, but work for another in the form of assignments. This is also how a dual organization would work. Each resource is employed by a system organization, but can work for a value based organization in the form of an assignment. This will allow you to manage value creation from a management perspective while still ensure quality and competence without fragmentation and duplication of roles. This dual organization is the basis for this work process, and we will expand on this topic in the other chapters.

As a developer your job is often not just to write code or configure systems. Many times you will be asked to provide technical support for things that are in the planning stages. This includes things like providing technical advice regarding new solutions and to make high level estimations. What type of activities are you expected to do outside of development?

If you want to become a Muse, then read this page for more information. These are the people that have inspired and challenged me in my work with this book in no particular order: @johanb - Design and frontend. Johan was one of my first Muses. @Kathy Tavlariou - Ecommerce. Kathy was one of my first Muses.

As a manager at the production level you are the last checkpoint before the teams. Your job is to organize incoming requests to ensure that the capacity match the requests. Unfortunately these requests usually comes through multiple channels and different means of communication, forcing you to manually trying to organize them in some form of coherent and useful way. Excel is a common tool here as is a high level of stress and that feeling that you have missed something. This is where portfolio management becomes a very handy tool. I call it the funnel of sanity. By directing everyone through one single point of communication you not only reduce the need to manually align things, you also get a tool to coordinate visually with all stakeholders. With a clear view of the capacity of the teams you manage and a single backlog of requests you can summon all stakeholders to prioritize together. That will reduce a lot of headache for you and it will be the first step to create a set of requirements to the stakeholders. The second requirement will be that in order for the priority meetings to be efficient there need to be a common ground for how the requests are defined in order to prioritize efficiently. It is very hard to compare programs with features and if the information and the estimations are using different variants, then the exercise will be very hard to conclude.

When you write something as complex as this book, then feedback becomes very important. Not only because I am not all knowing, but also because feedback can give new insights and learnings. As someone who always want to learn new things this is a great thing and I see feedback in the form of debates or constructive criticism as a positive thing. So anyone who provide feedback or inspire me with comments, links and research material is a person I consider a Muse. I reward this contribution by giving you a special title of recognition here on the site and I will mention you in the book as one of my Muses, if you allow me to do so of course. It is the very least I can do if you are kind enough to lend me your time to provide feedback.

Over the years I have worked with many methodologies and processes and to be honest none of them are inherently bad. I have taken plenty of things from for example ITIL, Scrum and Kanban that I think is very good and that I see people feel that it add value to the way they work. If we are being brutally honest here, then it does not really matter what methodology or process you want to use. The work is always the same. I know every organization always claim to be "unique" and that they need adaptation to whatever they implement, but I say that is a load of crap. The uniqueness has nothing to do with the work that need to be done, only how you choose to do the work. Ritualizing things does not change the work however, it just makes it more complicated. It does not matter if you put decision points or gates in your process, as long as you understand that those are not part of the work, it is just a manifestation of your lack of control that you try to satisfy. A lack of control that comes from weak work processes and a proxy based organization where you have managers with for the sole purpose or controlling and relay information. At the end of the day the work is still the same, regardless of your rituals. Since all methodologies and processes are rituals of some sort you can use any of them in your organization. As long as you understand what the rituals add in terms of value and the cost, then you will be fine. Almost all methodologies and processes are about control and clarity. Make sure you focus on the clarity bit and find other ways to ensure trust in your organization. You can also mix methodologies to have for example an ITIL based version for the business side and an Agile based version for the IT side. In fact, you can even have a mix of Kanban and Scrum side by side with Waterfall or RUP in the IT side and you will be just fine. As long as the connection between business and IT are solid with good portfolio management and requirement management, you can get away with most combinations. When you consider methodologies and processes it is a tip from me to make sure that you place the control based versions, like ITSM and Waterfall on the business side and the clarity based ones, like Scrum and Kanban, on the IT side. That is because of the need those two areas usually have. You should also make sure that that need are set up as a requirement in the other direction. So business will require data from IT to be able to control and IT require information from business to create clarity. The processes in his book is based on this need and I will do my best to describe the different parts of the process without the rituals and instead call it for what it is. This way you can place any methodology on to of it and see how it fit to the daily work that you actually do.

During my years as a consultant and owning my own design firm I noticed that many projects failed to deliver on time and/or on budget. Mostly this has nothing to do with the client or the consultant as it is a process problem. 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.

To say that there are some overlap and gray areas between requirements and business need is not an understatement. I have met many on both sides that clearly are not working as the role suggest. While this is not optimal in most cases it is not a problem to wear multiple hats, but it will make the work less clear and you are more likely to get burned out due to the workload. This is also a problem with requirements and business need that have a tendency to lead to a situation where you have huge and tiny tasks with various level of refinement all dropping into the development team. This is NOT a good idea and I have seen people become sick from stress and even leave their employment because of this. There is also a big gap in what activities

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.

coming soon

coming soon

coming soon

Coming soon

coming soon

coming soon

coming soon

Coming soon

coming soon

coming soon