When is a Tech Problem Not a Tech Problem?

The answer is “a lot of the time”.  Because Development are often seen as the end of the line for product development, they are also often seen as the cause of late or unstable delivery.  But the true answer often lies in looking up-stream to the start of the process.

Is your organisation clear on what it wants from a new product development?

Frequent problems are:

  • Lack of clarity and agreement on what the new product should do
  • Insufficient detail around what is being requested – while this allows for iterative delivery as teams discover and learn, it also takes time for the Tech folk to circle back and elicit the needed detail
  • A lack of clear ownership for the product – this is needed for clarity on who will have the final say on decisions regarding the product
  • A failure to document and keep up to date the product definition leading to conflicting understandings across teams

Are your priorities clear?

Common findings:

  • Priorities constantly change depending on which customer last shouted the loudest
  • Focus is often on short-term gains rather than longer-term game-changing priorities

Are you realistic about what can be achieved in the timescales?

Observations:

  • Development is squeezed as the deadlines for delivery draw closer
  • Time is allowed for the happy-day scenarios but insufficient time is allocated to edge-cases, QA and operational readiness
  • Prototypes are seen as near-final solutions and delivery promises are made accordingly without consulting Development

Are you joined up as an organisation?

Ask yourself:

  • Do you plan for product delivery end-to-end across the organisation?
  • When you go live, are all the stakeholders ready (Support, Installation/Deployment, Sales, Marketing, Finance, Legal)?

 

To achieve success efficiently and effectively, you need to be a well-oiled delivery machine.  If you need help, please contact interim.team.

Leave your reply