New Organisational Model For Project Based Companies

Elliot Goldratt suggested a Strategy Tree for project based companies. While that may work for some companies, it will not work for knowledge based workers or Software Development Companies, or Digital Agencies. On the other hand traditional resource planning and resource allocation is also not effective despite all the effort one put into it to make it less of a command and control model - Here I assume we know who are knowledge workers and how their productivity works, Peter Drucker has a fantastic article about Knowledge Workers that I highly recommend you to read, if you have not read it yet: http://www.forschungsnetzwerk.at/downloadpub/knowledge_workers_the_biggest_challenge.pdf 

Also, it has been proven that stable teams work better together on long term projects in software development. However, almost majority of software development companies or digital agencies break teams and reassemble them based on new projects or clients. This creates unnecessary complication and waste when the team starts to form again. A possible solution for this is to keep teams togather and allocate projects to existing teams (or ideally team pull projects). When they are done, then do not break the team, but find a new project for for them - This will put stress on New Business Development, and may force improvement and novel solutions to get new projects. The idea here is clear and simple but what else can be done to break the current organisational models of digital agencies or software project based companies ?

What I am writing about is based on my experience in digital agencies and software development organisations. What you will read below may not work in all cases and therefore I am not suggesting a complete method or framework, but one possibility out of many. Although I am talking about software company but below may work for any knowledge worker company that works based on projects and teams.

For the sake of simplicity, lets have a fictional organisation called OrgSoft. 

OrgSoft is a typical software development company. It has several layers of Vice Presidents, Management, Team Leads and the rest of the workers. Strategy is set from the top and communicated to the bottom. Projects are won based on tenders or sales team go out and bring projects. OrgSoft also has a PMO office and well organised project management process. They are able to run projects based on traditional project management, Scrum or Kanban or Disciplined Agile Delivery or anything in between (by now OrgSoft may be more advance than many digital agencies or software development companies in terms of project execution and agility.)

When they win a project, they assemble team sometimes, they need to sacrifices other less important projects in order to make the new client happy. Sometimes, resource allocation gets chaotic despite the fact that there are weekly project reviews and planning between Scrum Masters, Management and Project Managers. But, that is how things are and everyone take it as given, at the same time they try to improve things as they move forward. OrgSoft also has a support and maintenance team dealing with external and internal clients. They act as post production team for clients, and “try” to act as internal DevOps for internal development teams. Like any other organisation OrgSoft has different departments and specialisations, as well as supporting departments such as HR, Marketing, IT Services and etc. While orgSoft need to be more productive and “efficient”, they also must gain knowledge and be more innovative, lean, agile and all other cool stuff! 

But, We know from Cynefin Framework that to be Agile and innovative, you should navigate between and through Complex-Complicated Domains and sometime touch Chaotic domain for the sake of emerging solutions. However, the OrgSoft processes are taking it to an organisation with more constraints and rigidness - Despite all the cool agile and lean implementations. To reduce this rigidness, we must have less governing constraints and more of enabling constraints. So lets get to surgery:

1. We will break all the organisational hierarchy. No one is anyones' boss for now. This breaking gives us a system that we can shape. It may take us to Chaos for a short period of time. but we immediately put some enabling constraint around it.  
   
   
   
   • First constraint is the company itself. All people are member of this company and they act within its Boundaries.
   • Members should form teams. Every member must be part of one and only one team. This applies to everyone including executives, HR, Marketing and the rest. 
   • Teams may have team lead or they may not. It is up to them to define or introduce a team lead. They may decide to rotate in the role of team lead, or they may choose to not have team lead, but have a spokes person, they may also decide to rotate on spokesperson role. 
   • By now the organisation should look like this. Keep in mind that there is no hierarchy yet and there is no connections between these organisms. 
     
     
     
2. At the later stage of our evolution, teams define Explicit Rules of connections and they form a network of independent teams. 
3. They also agree to provide service to each other, there will be no blending but one team can provide service to another if needed. This will help to over come specialisations that may exist or skills or knowledge level. Or some teams may end up being specialise on certain domain. 
4. There are also other teams that only provide service to the rest of the organisation: HR, Marketing and Sales provide their own related services. There is also another team which act as experts in different areas. They get together as a team and provide domain expertise knowledge to the rest of the organisation.  Expert Teams may decide to dissolve their team and each join another teams to be more productive, but for now they decided to give it a try. 
5. Each team is also free to chose its internal way of working, some decide to work on Kanban model, another team decides to work based on Scrum, another team decides to do Extreme Programming, another team decides to do whatever they want. 
6. An executive team also has been formed. They agreed to be only Enablers, and coordinate the whole company. Nobody will report to them and they are not anyones' boss. They are Servant Leaders of the organisation. 
7. Service oriented design allows teams to focus on flow of work between teams. And the flow of work can be handled by Kanban. One of the responsibilities of executive team is to monitor the flow and help teams to balance demand and capacity between teams and to external parties. 
8. There is also a Business Development team, They go after new business.
9. Crews: Because New Business Team needs support from the rest of organisation in preparing proposals. OrgSoft agreed to introduce the concept of Crews. They agreed to have "New Proposal Crew". This is not a team, each crew members has certain responsibility and task and will not intervene other crew members. Because the roles and responsibilities are explicitly defined, Crews can form and disperse very quickly without going through team formation. So, OrgSoft New Proposal Crew forms when they are in preparation for a new project pitch, and after that is prepared and submitted they de-formed and go back to their teams. This does not mean that overtime they need to prepare a new business team, they only form crew from different teams, sometimes a Crew may be formed form one team. The point is that a Crew is temporary and it is not a team, and is tightly constraint for quick action, as each member has specific responsibility and task to execute. 

OrgSoft decides to experiment with hiring as well. Therefore, they decided to empower teams with hiring. Each team hires, team members can move around. Team divides to two like cells to create new teams as a scaling practice. If a team needs HR services, then it pulls HR services for hiring as well, otherwise it has full autonomy to act within the constraint of team purpose.

If needed, Each team can send their request to HR as a service request. HR and Recruitment Supporting Team collects all requirements from all teams, and ordered open positions based on Risk Profile that they created. They use multi-dimensional risk profiling for recruitment such as below. They defined five risk dimensions to help them prioritise recruitment. (More on risk profiling on another blog post)

The ordering defines in what sequence new candidate will be moved to each team. Although each team should pull the candidate, but it should also be a mutual agreement, the candidate should also agrees to join the team and selects, each candidate can also try teams and if they are happy they can stay with the team or decide to move to the next team in the sequence. Therefore, it is in the best interest of a team to be attractive. Such a goal enforces teams to constantly improve themselves and be a proud team to attract talent that they may need.

To scale, only a high performing team can be divided into two teams, and attract new team members. In cases that Larger teams may be needed, then two teams can combine to create a larger team. The number of team members will be decided just in time and based on the project and context they will operate in.

Project Portfolios are handled as a pool of projects and Clients. Each Project-Client will have its own multi-dimensional risk profile, and it is prioritised and sequenced based on the risk profiles. Teams pull projects as they have availability. The goal is then to match capacity with demand in a way that there will always demand (higher than capacity), capacity is not jammed. Therefore 100% utilisation is not the goal, but the goal becomes how not to have 100% utilisation, and have enough revenue and profit.  (I will cover portfolio management in such organisation later in another blog post).

In situations that a team does not want to divide into two team to handle a smaller project, then they accept two or more projects to work simultaneously. To prevent multi-tasking and have enough predictability. They use Kanban with multi-class of services for each project. One team member volunteers to coordinate flow of work and handle incoming works.

Related Posts: Breaking Hierarchies, and the birth of a Network Organisation at a Pure Project Based Company