The IT Project part one – seen from the Leadership perspective

This is the first in a series of two posts discussing the nature of the IT Project. 

We’ll in this post discuss the generally applicable characteristics of a modern IT Project seen from a Leadership perspective. This will be followed by a part two (update: here) taking the Technology perspective.

What is an "IT Project"?

Project technology sphereAn IT Project is a type of project with “just” one technology discipline – IT (in itself having a ton of different disciplines) – in contrast to multi-disciplinary projects including e.g., electronics, mechanics, physical production etc.

We’ll find IT Projects in a number of different contexts like:

    1. A Product Company developing own digital products
      Marty Cagan: “Great products solve real problems for our users and customers, in ways that our customers love, yet work for our business
      Modern and successful digital product companies have a strong Product Culture with stable and cross-functional Product Teams empowered to find the best solutions to business / customer problems … being held accountable for the Outcome.
    2. A Solution Provider doing development on behalf of customers / partners
      Could be an outsourced project, based on an agreed requirement specification. The Project Teams in this context are measured on Output … they cannot be held accountable for Outcome.
    3. Organizations running internal IT projects supporting the business itself
      Typically anchored in an internal IT-department responsible for e.g., ERP, CRM, provisioning systems etc.

Scenarios 2 and 3 are very much alike, in that they apply a Service Mindset servicing the customer (note: not the real end-customer / user) or the business, and focus on ad-hoc Project Teams providing Output. These “Project Teams” can be everything from the very classic team to the super Agile Scrum team.

Scenario 1 is radically different applying stable and empowered Product Teams to serve the real customer and be held accountable for the Outcome. Here you’ll find a strong Product Mindset in a strong Product Culture.

The Leadership perspective

Project TransformationThe purpose for all projects including IT Projects is, logically speaking, to convert customer/user problems/desires to solutions meeting these problems/desires. 

In the classic / sequential/ Waterfall approach this would mean 

    1. Develop and lock a fully comprehensive requirement specification
    2. Develop a solution and verify that all requirements are met
    3. Deliver the solution to users / customers

In the “old days” it was actually realistic not only to build an upfront and fully comprehensive requirement specification. It was also realistic that the user’s / customer’s needs were stable making the solution relevant when delivered.

Today’s fast-moving business environment, combined with an accelerating technology innovation speed, often makes this approach void.

This is part of the project’s context within which you need to design an approach strategy minimizing risks and optimizing value.

Approach strategy

The contemporary answer to this type of IT-context is an approach combining iterative processes with incremental solution building. In their new worthy-to-read book Product Discovery, Marcus Castenfors & Martin Christensen provide us with these definitions:

Iterative means the repetition of a process to collect feedback and improve things for the next time around.

Incremental means taking small steps, working in small batches, with each increment buliding on top of what has been built before.

Product Discovery by Marcus Castenfors & Martin Christensen

The trigger

In one form or another, what triggers (also) an IT project, is a problem or desire being the core in the projects purpose. Realizing that creating a fully comprehensive requirement specification is neither realistic nor desirable, the process often starts with a vision combined with a few high-level requirements.

We’ll use the Time Machine together with the customer making a jump in time to the point, when we’ve just closed the project. Being a strong facilitator, you’ll help the customer to describe the situation, now meeting his problems / desires with the developed solution. This situational description, combined with a few important and high-level requirements, forms the vision / North Star for the project. As recommended earlier, you’ll benefit from also creating a hierarchy-of-objectives.

The three pillars on which to initiate the IT Project are thus

    • A clearly stated purpose
    • A strong vision with a few top-level requirements supported by a balanced hierarchy-of-objectives
    • An approach strategy

Did you, as part of your approach strategy, chose to use the Scrum framework in some variant, you (read: Product Owner) would drive getting the Product Backlog initiated based on the initial foundation – the three pillars.

This post will not unfold the Scrum framework itself in details. A lot of info is available – just Google it.

The Leadership role

Seen from a project team perspective, the best you can do a as a leader, is to adapt a Servant Leadership mindset paving the way for the project. I’ve previously given my take on a Servant Leadership definition:

Porpose

Provide meaning

Provide direction

Empowerment

Empower

Support

Support

Dual-track agile

The aim in all projects is to be 

    • effective building the right solution / product
    • efficient building the solution / product the right way

This translates into what is often called Dual-Track Agile:

    • Product Discovery – finding the right solution to develop
    • Product Development – implementing the solution

Dual-track agileHaving an iterative/incremental approach strategy, we’ll see the two tracks exist and interact in parallel.

The Development / Delivery track is at the core of Scrum. Product Discovery is a deep rabbit-hole in its own right. We’ll not unfold it here in details; just raise the awareness of its importance. Find more on the subject in e.g., these worthy-to-read books:

Your challenge is to decide what works best for you in your specific context. One of the obvious advantages running a purely digital project, is the avoidance of the physical constraints in multidisciplinary projects.

Strategic organization of the work

Here we’ll shortly discuss two related topics:

Team Topology

Team ToplogiesThe assumption is here that you need more than “just” one project / product team to get to job done; in fact you’ve identified a need for a network of teams. The big question is now how to find an optimal design of each team and their relation in the network. “Optimal” is not a text-book thing. “Optimal” for you is what makes best sense in your context.

Especially when talking software development, you’ll find the book TEAM TOPOLOGIES a valuable asset. I’m sorry to repeat myself, but here is yet another rabbit-hole to explore.

In essence, Mathew Skelton and Manuel Pais suggest a number of building blocks, based on four team types and three interaction modes.

The four team types:

    • Stream-aligned team
    • Enabling team
    • Complicated-subsystem team
    • Platform team

and the three interaction modes:

    • Collaboration
    • X-as-a-Service
    • Facilitating

Yes – it can seem like bit of a mouthful, but the book is far from academic. In fact – it is clearly written by practitioners having been there and done that.

Team Topologies provides a practical, step-by-step, adaptive model for organizational design and team interaction, treating teams as the fundamental means of delivery, where team structures and communication pathways are able to evolve with technological and organizational maturity.

TEAM TOPOLOGIES

Cognitive Capacity

If you in some way are or have been involved in modern  software development, you’ll definitely appreciate the fact that a lot technologies exist out there. The advances in Cloud services have accelerated this universe making it virtually impossible to stay on-top of all innovations in IT technology. 

We as humans remain to have the same cognitive capacity meaning that one individual, say a full-stack developer, simply cannot know it all. Until we get some AI-implant in our brains, we have basically a few options to cope with cognitive overload:

    • Encapsulate knowledge and make it easily accessible via e.g., a Service Catalogue and/or Cloud technologies like Serverless computing 
    • Split knowledge / work between people / teams

We’ll return to the technology aspects in part two of this series.

Wrap-up

The approach to a modern IT Project is highly iterative/incremental because

    • the digital business environment is under constant pressure for change 
    • the underlying technologies are evolving at an exponential rate

Leadership’s ability to nurture the project execution environment and pave the way, is equally important as highly competent teams.

Stay tuned for the up-coming part two (update: here), with focus on the technologies in an IT Project.

Projekt.dk