Digital projects have some unique characteristics that make building teams to deliver them a challenge:
- Rapidly changing technology
- Diverse, evolving user trends
- Evolving threat landscape
- Fast moving external actors
- Continuous delivery
Having spent over 20 years delivering digital projects, I use a simplified model of the project process and an approach which categorises the skills required within that model to help me resource digital projects and communicate resourcing requirements with stakeholders.
The Project Model
The first problem I usually encounter when looking at a digital project is that the project owner is using a model that is fundamentally flawed. The most common flaw is to focus too tightly on the production phase and have a project plan ending with a milestone, ‘Project Complete’.
On the production side, this milestone is an endpoint, whereas on the operation side this milestone a start point. Agile methodologies address this with continuous integration/continuous delivery (CI/CD ) approaches and are better at delivering outcomes but are not very helpful in team resource planning.
The simplified model I have found most useful (and easily understood in planning digital project teams) I call the Launch-Orbit model. It is based upon an analogy of staged space vehicle launch. The generally accepted phases are:
I like the model because all stakeholders get to clearly understand:
- That there are distinct phases requiring different resources
- Orbit is a state that needs to be maintained and is very different from ‘Complete’
- Customer return on investment (ROI) doesn’t start until the payload starts to deliver its potential
- Payload ROI needs to continue, possibly indefinitely
- Everyone needs to be on board before liftoff
To come back to digital projects, let’s apply these stages to an e-commerce website development:
Ignition/Liftoff: The goals of the project are finalised and the financial and human resources are acquired/identified and reserved to achieve Payload ROI. Project managers and resource owners are required to ensure the project ignites and lifts off smoothly.
Main Engine Burn: An intense period of effort doing the main heavy lifting on the project: architecture; design; coding; integration; infrastructure. The resources needed will be digital architects, coders, system admins, database admins, graphic designers, UX and AX specialists, scrum masters and other agile practitioners. The end of this phase is often a minimum viable product (MVP).
Separation: A significant part of the team may no longer be required to achieve Payload ROI. If the core database structures are done, the main modules developed and external systems integrated then those specialists must be released. Separation is not optional as the team dynamic and overall ‘weight’ of the team needs to change.
Second Stage Burn: The part of the project where UX and AX are tested and refined and where content is created. Third party integrations are tested and readied for production. The end of this phase is the first release candidate for the system.
Payload Separation: The site or service is launched to the user base and made live. Once again the UX/AX and content creation skills need to be reduced or removed altogether.
Payload Orbit: Establish stable operation. Product managers will be using product feeds live and real user feedback will be coming in, along with real orders for processing. Content managers, SEO and Social Media specialists will be required to maintain the optimum orbit.
Payload ROI: Build, measure, learn (BML) processing kicks in to achieve ongoing ROI. It will require a multidisciplinary team of product managers, content authors, SEO and social media specialists. There may be a small requirement for more in-depth front-end and back-end skills, however, a large requirement here indicates that one of the preceding phases was not 100% successful.
Defining Skill/Resource Categories
Within the Launch-Orbit model we can clearly see three skills categories:
- Main Engine Resources: Designers (graphic, AX, UX), module developers, database developers, programmers, integration engineers, UX/AX developers. Typical specific skills might be PHP, SQL, Drupal 8 module dev, HTML, CSS, Javascript, front end and back end frameworks, version control etc.
- Second Stage Resources: Designers (content), AX/UX developers, system managers. Typical specific skills might be Drupal 8 blocks and views, rich media creation and manipulation, copywriting, HTML, CSS, Javascript, user testing, process management.
- Payload Resources: Product managers, SEO developers, social media developers, content developers. Typical specific skills might be Drupal 8 content management, Google analytics and advertising services.
I also add a fourth category to this set, Ground Control Resources. These skills are those that are needed throughout the project lifecycle to provide fundamental services, maintenance and monitoring. Typical skills included here are data centre specialists, network and security specialists, system admins, operating system maintenance engineers. They are needed longer than any of the other skill sets, and the payload depends upon them, but payload ROI cannot be significantly influenced using them.
How Does This Help?
This approach helps to highlight the multidimensional, changing nature of the team in a simple way so that project owners can make the right decisions in resourcing. It helps to identify where hiring employees vs agency project services vs retained services should be used.
Take a project owner of a new ecommerce website for a product manufacturer, for example, they might break down their team building strategy as follows:
- Ground Control: Retained services
- Main Engine: 90/10 mix agency/employee
- Second Stage: 70/30 mix of agency/employee
- Payload: 80/20 mix of employee/agency
From this, our project owner can clearly see that direct hires are being made in areas that will directly affect ongoing ROI. In addition, by using the right type of resources in the right stages of the project the needed separation is facilitated and natural.
This approach also helps focus on the recruitment effort. I can’t count the number of times I've seen poorly focused job specifications from project owners, such as:
- Advanced HTML5/CSS3 hand-coding skills combined with Ajax, JQuery and Javascript
- Advanced Drupal/WordPress architecture experience, standard methodologies and coding standard
- Experience in the development and testing of responsive websites for multiple browsers, platforms and devices
- Proficiency in Linux administration, Apache configuration, MySQL database design and PHP web development
- Strong knowledge of PHP and MySQL including modern PHP frameworks such as Symfony and Laravel
- Object Oriented Programming and Design Patterns
- Version Control Systems - ideally Subversion or Git
- Good working knowledge of web and mobile UX/UI best practices
- Experience of Automated testing, such as PhpUnit, Behat or Selenium, automated deployment and continuous integration (Travis, Jenkins) would be of advantage but is not essential
Anyone can now clearly identify Ground Control skills, Main Engine skills and Second Stage skills, even Payload skills in that list. It becomes obvious that this is a hire where the separation phases haven’t been considered. The result will either be a highly stressed person working pretty much on their own, or a compromised hire where some of the required skills are simply not there, potentially jeopardising the project.
In reality, this type of job specification is just a collection of buzz words that would scare off anyone with the real skills needed, and when the project owner reviews it that becomes obvious.
To Conclude
The Launch-Orbit model (and less developed versions thereof) have served me well over decades of building teams for digital development. It might be called simplistic or even naive, but that is where its true strength lies. It is very easily understood by all levels and experience of team members and management, yet highlights flawed resource planning that might go unnoticed otherwise. Furthermore, because it is a high level, slightly abstract approach, it has neatly accommodated all of the new techniques in software development, online technology and project management that have come along in my career. It can be extended when considering CI/CD or a fixed release process as these can be characterised as ‘orbit adjustments’, but that is for another article.
The final benefit it has given me, as a provider of extensive Ground Control and Main Engine services, is the excuse to tell the project owner that it IS rocket science!