The biggest bugbear with one of the many roles I perform is the misconception that technical project management is just a fancier name for project management. It really isn’t. 

Technical Project Management and Project Managers more generally have some shared elements.

• Reporting on task progress
• Raising issues and risks
• Tracking actions
• Tracking burn/spend

But technical project managers/delivery managers – whatever your particular company or sector likes to call them, perform a bunch of tasks that is really niche to their skill set.  What we bring to the table is the ability to understand, at a software and hardware level, the moving parts and dependencies.  Our mantra is to work closely with the technical teams; from the strategic Enterprise Architects, through Solution Architects all the way to the development teams within.  We are usually techies at our core and can understand the technical intricacies a project manager can’t, and shouldn’t be expected to. We are the people you want on your complex multiple supplier projects to make sure everyone is moving towards the same goal.

To give an example; when Developer A with Supplier A complains that the API from Supplier B isn’t working a PM will quite rightly report, track and escalate the issue.  A TPM will review the API docs, set up and execute calls to check the nominated API, will review Developer A’s issues to help better identify where the problem lies using a mix of business/project domain knowledge and technical know how. Is it the API?  Is it Developer A’s misunderstanding of the business use case?  Is it a misunderstanding of the domain model?

Aside from dealing with specific problems, we are able to provide a holistic view across the technical delivery to ensure the project doesn’t fall into the trap of siloed development and delivery.  We are able to consider business processes and identify what technical changes are required across all suppliers. We will consider your architecture and strategy, your CRM, your website, your reports, your emails, your finance system; we’ll consider the impact to migration scripts and deploy plans; we’ll do all of this without really needing to think about it.  Because this is the core of our skillset and approach.

Now don’t get me wrong – I am not saying we know the guts of all the technical changes needed for each system but we will know where the crossovers start and end, and will ensure you are not surprised with only 60% of your process working.

So what happens when you don’t have someone like us at your disposal? 

Well, large scale software projects have many reasons they fail to deliver on time/budget. Its usually blamed on one or more of the following

• Poor requirements
• Scope creep
• Poor planning
• Poor communication
• Lack of Project management

Whilst Lack of Project Management looks and smells like what we are talking about here, for all the reasons listed above it is not.

If you don’t have strong technical oversight and management for a complex software project across multiple suppliers then how do all the things I am talking about actually happen?   Well the short answer is they happen reactively when things go wrong. 

Think of this as an example..

• The website owner spots a hole in a bit of functional delivery for the website
• It gets raised and logged with the web team to add the feature
• The change is developed and deployed for testing
• On testing your website owner realises that this feature now means that the CRM team need additional information feeding into their database, so now you request a further change
• Again this goes into the hopper and is scheduled for dev
• Once deployed, web owner and CRM owner test again. All good.
• Then your finance person starts their testing and realises they also need this new bit of data.
• You get the picture ….. morale drops, delivery slows, functionality is stalled.. and the cycle repeats again.. and again..

I see this pattern over and over, and it burns so much time and money.  Having the correct people on your project team is worth its weight in gold.  Not only does it stop the overburn of time and money but it reduces project frustrations and leads to a better end product.

The happiest marriage is to use PM’s and TPM’s together on large projects.  Let your technical guys really get into the low level detail and provide information to the PM.  Let your PM do what they are good at and don’t draw them into tech discussions that won’t help them and from which they can't help with a solution.

So, what's the conclusion?

Big complex projects are hard and challenging for all the obvious reasons.  However, this can be offset by building your team correctly in the first place and ensuring you have the right roles and responsibilities.