A developers kryptonite is the “big project” and it scares the big red pants off them. Large projects are daunting, take months (if not years) to implement, take a huge amount of joined up effort, not forgetting spanning a long period of an ever-changing personal life that both affects and gets affected by the gigantathon!

So, how do we make a big project both a success in terms of meeting the business needs and not destroying the engineering team at the same time…

To me, project success is highly dependent on the whole team having the backing of engaged sponsors and a well-functioning steering committee. Focussed on and endorsing the process and business practices that the engineering team work to. Without this level of engagement you can almost say goodbye to that dream goal and probably your developers sanity.

A lack of focus and a step outside of a well-defined process lead to significant disruption, stress, and fear. That anxiety often transfers upward onto already pressurised stakeholders and despite all efforts to mitigate disputes with them, issues crop up which inevitably lead to at-risk projects and goals that seem as far away as Mars!

Introducing the #ConstructionFlow

My life is full of projects, the most recent being the purchase of a dilapidated 1920’s Victorian house that’s in need of complete restoration. The principals I’ll apply to rebuilding this apply to software/web development projects too, most notably:

Define the process, hire the right people, communicate.

Simple, yes?

No. Issues with the people element will always arise in a project lifecycle, these can be managed. A plumber can be replaced, a bad design can be redesigned, a bad mood can be improved, but a bad process once you’re all on board, can’t. The project will fall apart and the impact is often catastrophic, creating panic, frustration and other unruly behaviours…

For instance, an unfocussed passive aggressive stakeholder, whom may say they are in support of the project will object or create obstacles to derail or delay it at every opportunity. In order to cope with their own derailment they’ll likely blame the process; creating additional unnecessary meetings or work, all the while verbalising their commitment to the project.

This behaviour won’t get you to your end goal, it’ll be a stress-inducing, morale-sapping, trust-depleting disaster.

Using the “you wouldn’t build a house without having an architect design it first” analogy is a useful headline to describe all of the components needed to deliver a successful digital project. Satisfying the needs of those developing the product is key to that delivery.

The minimum resource requirements to the #ConstructionFlow are…

The (soon-to-be) homeowner (or client)

Role – This person has a vision, a vision that inspires them to part with their hard-earned cash and embark on a project of building their dream home.

Responsibilities:

• To provide as clear a brief as possible to the architect
• To set out clearly the objectives and aspirations

Equivalent = The founder or head of business area (usually the stakeholder)

Role – To come up with the ideas that differentiate the business from it’s competitors, the visionaries and the disrupters!

Responsibilities:

• To set out the intent and purpose of the vision
• To define the objectives and goals of the project

 

The architect

Role – The architect works with the homeowner to outline plans for exactly how the house will look.

Responsibilities:

• To provide information that is relevant to the proposed building and which may have some bearing upon it
• To design the specific guidelines for contractors to pickup and work from
• To outline costs of the work involved

Equivalent = The product manager/owner

Role – Research the wider requirements to deliver the vision and provide a framework for detailing those.

Responsibilities:

• To assess the viability to project
• To engage with the UX team to understand the opportunities and design a solution
• To document user scenarios that tell a story of what the product should do

 

 

The main contractor

Role – The company chosen to implement the architects design and bring in the required team; electricians, plumbers, builders, etc.

Responsibilities:

• To assemble the team of people needed for the job
• To schedule the work required
• To try and avoid, as much as is reasonably possible, any changes in the design brief or any late requests for additional work. If and when such changes and late requests are instructed, to understand that this would lead to additional costs

Equivalent = The project manager or ScrumMaster

Role – To facilitate the discussions between the product owner and the team assembled to work on the product, and to create a cross-functional operation across business areas.

Responsibilities:

• To remove obstacles and impediments that prevent the flow of work happening
• To push back on change to avoid affecting productivity and morale-affecting scope creep caused by late requests
• To monitor the effectiveness of the teams’ estimations and planning

 

The foreman

Role – Often known as the “specialist” as the foreman has usually been there, and done that many times before and has the experience to lead other contractors. The primary role is to manage the team and complete the project on time and to budget.

Responsibilities:

• To organise tools, machinery, materials and contractors
• To supervise construction activities
• To ensure construction is carried out accurately, following plans and specifications
• To ensure that contractor activities are co-ordinated
• To ensure that tasks are completed on time and to the required quality standards
• To communicate project progress back to the stakeholders
• To maintain detailed and accurate site reports

Equivalent = (this is where it gets a little tricky) The CTO and/or The UX team and/or The head of development

Role – Be the Mark Zuckerberg, not the Adam D’Angelo. Although the primary focus should be to get the product live, importantly it’s to scope out the work, not being the technical expert, but to know the technologies available and what needs to be done to accomplish the goals.

Responsibilities:

• To define the infrastructure and engineering team resources required
• To translate use cases into clear technical tasks
• To monitor development activity
• To ensure that best practices are used and the architecture of the solution is future-proof
• To oversee task estimations and team resources (time vs personnel)
• To perform code reviews and provide adequate training if needed
• To communicate project progress back to the business

 

The builder, plumber, electrician, etc.

Role – Perform the tasks by following the plans and specifications

Responsibilities:

• To provide an estimation of the amount of work required
• To report on any problems whilst doing the work
• To complete the work to the required standards

Equivalent = The developer

Role – Transform the requirements from technical tasks to application code

Responsibilities:

• To provide an estimation of the amount of time needed
• To report on any problems whilst doing the task
• To complete the development to the required standards

 

The construction inspector/surveyor

Role – To confirm compliance with regulations and that building work was followed to the plans

Responsibilities:

• To review and approve plans in accordance with regulations
• To inspect and monitor construction sites to ensure overall adherence
• Apply the use of survey instruments, metering devices, and test equipment to perform inspections
• Verify structural integrity to ensure building compliance
• To issue stop-work orders until building is compliant
• To keep daily logs, including photographs taken during inspection

Equivalent = The quality analyst

Role – To sign-off development work based on it matching the criteria set-out by the initial requirement

Responsibilities:

• To be aware of the project deliverables and understand the plans
• To perform manual and automated test scenarios that perform the user action requirements of the feature
• To apply the use of testing software and devices to support the investigations
• To detect and highlight errors in the application
• To assist in fixing the process leading to failures in the development lifecycle

 

In summary

See how similar these roles and responsibilities are? Software and web development really is no different to other forms of development, at least in terms of project resource needed.

For an engineering team to be successful in a large project (and still be around at the end of it!), they need the process to be followed. You often hear people saying “coding is like some black art”, and it kind of is, coding is hard and not for the fainthearted. The role of the developer is to take a good set of requirements and turn them into structured computational instructions, which in turn fulfil the goals of the project. Without that being in place from the beginning, how can the developer be expected to deliver…

#ConstructionFlow == Project success.

ps. We’re still a little super :)