How difficult should it be?

The basics of a team structure to drive from continuos customer dialog to delivery of result.

1. The Need Team
   1. Someone submits an idea for review (basically a change request from anyone)
   2. The team reviews the idea and assigns it a status
   3. Inform the other teams of relevant status constantly
   4. Inform the stakeholders (don’t forget the Someone) of relevant status constantly
2. The Architecture Team
   1. The idea is investigated to reveal it’s constituent parts
   2. The team runs several impact analyses on the repository based upon data about the idea
   3. Define the would be result of the change as part of a transition architecture
   4. Inform the other teams of relevant status constantly
3. The Program Team
   1. Create a change proposal (could be a project or some other type of job)
   2. Submit the change proposal and review it
   3. Prioritize among the changes in the portfolio
   4. Perform a trade off analysis
   5. Inform the other teams of relevant status constantly
4. The Production Manager Team
   1. Investigate resource utilization (Resource plan)
   2. Update the list of things to do (backlog) with the new change
   3. Assign responsible (project manager/team) to the task of resolving the change
   4. Inform the other teams of relevant status constantly
5. The Task Team
   1. Analyse and plan work (sprints)
   2. Do work and make sure it works
   3. Inform the other teams of relevant status constantly
   4. Deliver result
6. The Production Team
   1. Prepare production to receive result
   2. Put result into production
   3. Monitor result in production
   4. Inform the other teams of relevant status constantly

Guiding thoughts:

• An individual could participate in many teams
• Yes, there need to be some separation of concern when working with larger changes
• No, not all things end up as software
• Configure if the urge is there
• Consensus is a good state but may not always be reached
• Think different, think for your selves

The Project Business Model SWOT

This post is the sixth in a series of ten about real life experiences of using business model thinking as a foundation for planning and delivering change. Writing this post I’ve had the help of a true friend and admirable colleague (Eva Kammerfors) whom I’ve shared many of the referred to business model experiences with.

The Project Business Model SWOT

This a simple SWOT covering the basic assumptions you have over the external and internal forces influencing the project. The enhancers are forces that work to make your project a success. The silencers are forces that work to make your project disappear from the change radar.

Make sure that you follow the business model component structure when outlining the SWOT, to ensure that people easily can relate the work back to the Project Business Model Canvas. When we design the SWOT cards we follow these three simple rules:

1. Internal forces should focus on business model components from the left side, that is Key partners, Key resources, Key activities.
2.  External forces should focus on business model components from the right side, that is Customer segment, Relationships, Channels.
3. All quadrants can use the business model components Value propositions, Effects, Revenue streams, Cost structure.

 

 

When you plan the project SWOT, do so in a workshop format. Give everyone a set of cards that they can outline their own view of the work on, then merge all cards on a wall sized card. After the merge the group can prioritize using dots or any other marker on the wall sized card. Don’t forget to work the conclusions from the SWOT exercise back into the material you have created and consider in all the future material.

This is as all the work in The Project Business Model a highly participative and visual way of creating the understanding of the project results and effects. 

______________________

Earlier in the Project Business Model series of posts:

1. The Project Business Model

2. The Project Business Model Profile

3. The Project Business Model Results

4. The Project Business Model Timeline

5. The Project Business Model Sprintlines

Next in the Project Business Model series of posts:

7. The Project Business Model Blue Ocean Strategy

8. The Project Business Model Principles

9. The Project Business Model Stakeholder Groups

10. The Project Business Model Stakeholder Impacts

The Project Business Sprintlines

This post is the fifth in a series of ten about real life experiences of using business model thinking as a foundation for planning and delivering change. Writing this post I’ve had the help of a true friend and admirable colleague (Eva Kammerfors) whom I’ve shared many of the referred to business model experiences with.

The Project Business Model Sprintlines

When we plan and execute our changes we may end up on levels where people aren’t perhaps used to or see the benefit from working with scrum and agile techniques. On other areas of the solution space (primarily software development) people are used to these agile techniques and practice them with great satisfaction. Our work then is to merge the views of all these people into a planning instrument that can cater for all their ways, so we can have the best from them all.

One way of solving this problem is to pull it together in “sprintlines”. In this case we have within each grey box a planning area containing a first cut product backlog from which each team would create their sprints. We use the word sprintline to refer to the horizontal lines as we have found it easier to connect the detailed planning with higher order planning in this way.

When you plan the project sprintlines, do so in a workshop format. Give everyone a set of cards that they can outline their own view of the work on, then merge all cards on a wall sized card. After the merge the group can prioritize using dots or any other marker on the wall sized card. If possible use rules of thumb from scrum and other methods to correctly size and match the work. Refine the work on scrum boards and whatever other tools are necessary just be sure to aggregate it up to the programme and portfolio levels so we can have an investment view on it all.

This is as all the work in The Project Business Model a highly participative and visual way of creating the understanding of the project results and effects. 

______________________

Earlier in the Project Business Model series of posts:

1. The Project Business Model

2. The Project Business Model Profile

3. The Project Business Model Results

4. The Project Business Model Timeline

Next in the Project Business Model series of posts:

6. The Project Business Model SWOT

7. The Project Business Model Blue Ocean Strategy

8. The Project Business Model Principles

9. The Project Business Model Stakeholder Groups

10. The Project Business Model Stakeholder Impacts

The Project Business Model Timeline

This post is the fourth in a series of ten about real life experiences of using business model thinking as a foundation for planning and delivering change. Writing this post I’ve had the help of a true friend and admirable colleague (Eva Kammerfors) whom I’ve shared many of the referred to business model experiences with.

The Project Business Model Timeline

The cue here is that value rises to the top and is released through the yellow date bubbles. If you work in an environment where the appetite for release is higher, then you could add smaller grey/red date bubbles. These grey/red bubbles would contain the outcomes of each sprint as it is related to a result, shown here as red rectangles. (More on sprints in the next post)

When you plan the project timelines work with the result card you created earlier and try to capture the essential release dates from a business perspective. Do the job in a workshop format. Give everyone all the cards created so far and a set of empty timeline cards that they can outline their own view of the projects on, then merge all cards on a wall sized card. After the merge the group can prioritize using dots or any other marker on the wall sized card.

This is as all the work in The Project Business Model a highly participative and visual way of creating the understanding of the project results and effects. 

______________________

Earlier in the Project Business Model series of posts:

1. The Project Business Model

2. The Project Business Model Profile

3. The Project Business Model Results

Next in the Project Business Model series of posts:

5. The Project Business Model Sprintlines

6. The Project Business Model SWOT

7. The Project Business Model Blue Ocean Strategy

8. The Project Business Model Principles

9. The Project Business Model Stakeholder Groups

10. The Project Business Model Stakeholder Impacts

The Project Business Model Results

This post is the third in a series of ten about real life experiences of using business model thinking as a foundation for planning and delivering change. Writing this post I’ve had the help of a true friend and admirable colleague (Eva Kammerfors) whom I’ve shared many of the referred to business model experiences with.

The Project Business Model Results

A value proposition is a promise about value. We care a lot about our promises so we start our project design with focus on understanding the customers effect and then we craft the results the project should generate to help the customer reach the effects.

The effects puts a focus on the customer perspective through understanding what effects (monetary and non-monetary) the project will deliver against and when.

The results puts a focus on the supplier perspective through understanding what results (product, service, services) the project will create to deliver against the specified effects.

When you plan the project effects and results, do so in a workshop format. Give everyone a set of cards that they can outline their own view of the projects on, then merge all cards on a wall sized card. After the merge the group can prioritize using dots or any other marker on the wall sized card.

This is as all the work in The Project Business Model a highly participative and visual way of creating the understanding of the project results and effects. 

______________________

Earlier in the Project Business Model series of posts:

1. The Project Business Model

2. The project Business Model Profile

Next in the Project Business Model series of posts:

4. The Project Business Model Timeline

5. The Project Business Model Sprintlines

6. The Project Business Model SWOT

7. The Project Business Model Blue Ocean Strategy

8. The Project Business Model Principles

9. The Project Business Model Stakeholder Groups

10. The Project Business Model Stakeholder Impacts

The Project Business Model Profile

This post is the second in a series of ten about real life experiences of using business model thinking as a foundation for planning and delivering change. Writing this post I’ve had the help of a true friend and admirable colleague (Eva Kammerfors) whom I’ve shared many of the referred to business model experiences with.

The Project Business Model Profile

The focus on this is to add or remove any dimension that the people designing the project would want to profile it on. The classic way of doing project profiling is to use the Time, Cost and Quality dimensions, we like it to be a bit more flexible and so we allow people to choose dimensions as they see fit. In the sample below adding the risk dimension enables organisations governing on risk as the major dimension to express that in their project profiles. Likewise adding the capability dimension enables organisations to have the project focus on knowledge transfer.

In this sample there is only one project. If you are planning a multi project programme then you’d see shared dimensions and weights on the relations. Having the weights on the relations increases the likelihood of fantastic insights into the portfolio of projects.

When you plan the project profile, do so in a workshop format. Give everyone a set of cards that they can outline their own view of the projects on, then merge all cards on a wall sized card. After the merge the group can prioritize using dots or any other marker on the wall sized card.

______________________

Earlier in the Project Business Model series of posts:

1. The Project Business Model

Next in the Project Business Model series of posts:

3. The Project Business Model Results

4. The Project Business Model Timeline

5. The Project Business Model Sprintlines

6. The Project Business Model SWOT

7. The Project Business Model Blue Ocean Strategy

8. The Project Business Model Principles

9. The Project Business Model Stakeholder Groups

10. The Project Business Model Stakeholder Impacts

Planning the contribution of the leader among architects

In an earlier post I’ve laid out the Wheel of Leadership as a tool for the leader among architects. In this post I’ll visualize some of the approaches one can have as one employ the Wheel of Leadership.

Pure forward flow

In the pure forward flow each part of the wheel of leadership is addressed and completed prior to working with another part.

 

Design first flow

In this approach the design of the management structure is completed prior to realization.

 

Continuos cycle flow

In this approach design, test and execution is a continuos cycle with reinforcing loops over each specific topic.

 

Pure agile flow

In this approach design, test and execution is a complete activity locked in a continuos cycle across all of the topics.

 

Have you found your natural rhythm?

Life as an architect is not always so easy, we are sometimes overwhelmed with things to do and the more things amass the worse it gets. My usual remedy for situations like that is that you just STOP what you are doing and go for a walk. As you walk let your mind drift and try to just be in the moment. When you get back to wherever you do your work, then you can use a tool like The Four Corners of Focus as a guide to get in to the natural rhythm of things.

Here is how it works

1. Capture the key issues of the current situation as it unfolds across the five perspectives of The Flow of Effort
2. Map each issue into what would seem an appropriate quadrant of The Four Corners of Focus
   
3. Assess each issue found in the dark grey quadrants and make a choice on how to use The Wheel of Leadership to move the issue from its current state into the quadrant of natural rhythm.

The contribution of the leader among architects

The Contribution of the leader among architects can be considered using the wheel of leadership from The Art of Enterprise Architecture.