The Golden Circle

In this post I share a snippet of information referenced from the book Start with Why by Simon Sinek. The ideas and concepts provided in the book talk mostly about how some companies are more successful than others (using Apple as a major theme). It advocates that most companies often don't take time to appreciate the WHY they in business in the first place, and more often focus on WHAT they do. By focusing on the WHAT they tend to lose a captive customer audience, failing to address to the core beliefs of customers, which is one of the main reasons customers choose to go a brand, or become an ardent follower of the company.

I found this pretty interesting, with a wider relevance outside of just corporate strategic management. The golden circle can be applied to both personal and professional topics, and links nicely to my RAGE model. It can also be applied to team structures as well. In fact, in the organisational sense, the golden circle flows from top-to-bottom: starting with the company vision and flowing down to each person in the company.

What follows is the core explanation from the book, chapter 3, The Golden Circle. Simon Sinek's TED talk is also one of the highest ranking talks on TED, video is embedded at the end of this post. Although Sinek makes reference to many stories and cases that appear as old news in today's time, they are still nevertheless relevant, at the very least a useful reminder...

The Golden Circle

According to Sinek, the golden circle can be used as a guide to vastly improving leadership, corporate culture, hiring, product development, sales and marketing. It even explains loyalty and how to create enough momentum to turn an idea into a social movement. And it all starts from the inside out. It all starts with Why.

Starting from the outside in, Sinek describes the terns:

WHAT: Every single company and organisation on the planet knows WHAT they do. This is true no matter or big or small, not matter what the industry. Everyone is able to describe the products or services a company sells or the job function they have within that system. WHATs are easy to identify.

HOW: Some companies and people know HOW they do WHAT they do. Whether you call them a "differentiating value proposition", "proprietary process" or "unique selling proposition," HOWs are often given to explain how something is different or better. Not as obvious as WHATs, many think these are the differentiating or motivating factors in a decision. It would be false to assume that's all that is required. There is one missing detail:

WHY: Very few people or companies can clearly articulate WHY they do WHAT they do. When I say WHY, I don't mean to make money - that's a result. By WHY I mean what is your purpose, cause or belief? WHY does your company exist? WHY do you get out of bed every morning? And WHY should anyone care?

When most organisations or people think, act or communicate they do so from the outside in, from WHAT to WHY. And for good reason - they go from the clearest thing to the fuzziest thing. We say WHAT we do, we sometimes say HOW we do it, but we rarely say WHY we do WHAT we do.

But not the inspired companies. No the inspired leaders. Every single one of them, regardless of their size or their industry, thinks, acts and communicates from the inside out. They start with WHY...

Get the book, watch the video!

On E2E architect role in projects

I have shared my thoughts in the past on the subject of architects in the domain of digital TV software systems which can be found here. In this post I will share further thoughts about the specific role of an E2E (End-to-End) architect from a program/project management perspective, including my expectations of the role as well as the associated challenges I've faced with this concept, especially where the role either does not exist, or is not clearly defined in cases where companies don't have a clear enough understanding or have not yet set up a formal architecture competency.

My Background & My possible Anchor Bias

In my first decade of working experience with software and systems engineering projects, I was fortunate to work with world class technology service providers (S3 in Ireland & NDS/Cisco in UK). This experience helped shaped the way I would view future technology projects, including product & project management, software engineering, integration and delivery functions. It's the kind of experience that never leaves you, especially when you've witnessed first hand, one successful delivery after another both as an engineer and manager. So I'd come to see the world in a particular light, taking with me the style of project execution where ever I went, and assumed that all companies naturally followed similar concepts. And the cool thing about this experience was a well grounded appreciation for software & systems engineering design principles - principles which should not be confused with implementation methods, as what is a hot topic of debate these days, that of Agile V Waterfall, that has been the bulk of my recent challenges in projects in the last six years.

On returning back home to South Africa* still working in Digital Media TV domain, I soon realised that things are a little different to say the least (absence of architect roles, working with business analysts where I'd been used to analysis being a function of architecture, no defined role of systems integration, no method of continuous delivery & lack of solid post-launch monitoring & operations support systems). My first major program, involved a large-scale overhaul of the end-to-end broadcast system, including a video-on-demand component and a new set top box software stack. In order for the program to have a decent chance of success, I not only had to restructure & reshape the program, but also had to introduce functional roles that for me, were always obvious: an architecture team with a specific role of E2E architect, E2E systems integration, test and delivery teams. With a lot of hard work of convincing senior management these roles were necessary for project delivery, we managed to implement the structures I proposed that ultimately helped in the successful delivery of the project.

Strangely enough, as I took on other engagements in large programs in the same group of companies, I found myself repeating the same. It could be because I have a bias that is so strong and deep that does not allow me to see any other way, even though I always try to adapt my style to the culture and teams currently at my disposal, yet I still find myself coming back to these principles because its been proven and tested, that I can't really find any real fault in - possibly it is because these are indeed engineering principles that have stood the test of time, especially this concept of an End-to-End Solution Architect role. As the saying goes, never leave home without it, if I'm running a large program of work, that involves many systems & component suppliers, I never run a program without having an E2E architect attached to my programs, as step one. Once that is established (often as a result of canvassing support which takes up some time and energy), I move on to structuring the role of E2E systems integration, which in turn drives the processes and behaviours expected from component engineering and test teams. The program timeline then shows a simple picture of the high-level milestones involved, where the bulk of the program management and execution is a function of coordinating delivery plans with respective project delivery teams (who maintain the detailed project plans) as well as managing stakeholder engagement (which is a vital component of running large programs). This hasn't been smooth sailing all the time, as I'll try to share some of the challenges that frequently come up, later on in this post.

*Disclaimer: Although my writing is about an experience with primarily one industry domain in South Africa (Digital PayTV), I'm mindful about not passing a broad value judgement against all large corporates with a software competency. At first I thought these challenges of projects and roles like BAs for example was limited to just this environment, but the more I researched by skimming through job specs, attending networking events, technical conferences, meetups, training courses and meeting people from other corporates, I later realised the patterns run across all the major corporates like financial services, banking and the big telcos, that more often than not, the structures in place mirror more traditional-IT governance than hardcore technical software development structures that I was used to, in working in a pure technology services environment. So I'm reasonably confident there is no broad value judgement being applied here, that these experiences are likely to resonate with large companies operating outside PayTV.

Typical Landscape

The picture below aims to illustrate a typical landscape of this ecosystem. This could be separate entities run independently, or even group under a technology division, with different functional expertise, that in reality are still perceived as separate silos of responsibility:

This picture speaks to a typical reality of technology service providers in a digital TV value chain. Each silo represents a set of core technology expertise that exist in separate functional lines either under a technology division, or could exist as separate lines of business altogether. 

Each silo may have its own set of speciality with architects and development teams. Each unit may also likely to have a very unique culture: people, skill-set and ways of working. Each silo may also have its own operating model: how work gets prioritised and injected, build, test and release procedures. These units might also have their own terminology, a lexicon / vocabulary for their specific domains. They may also not be entirely self-sufficient, relying on external third-party component suppliers that form part of their system. These third-party suppliers are just like another silo, each with their own operating model, from architects to development teams, to ways of working as stipulated by their underlying contractual agreements.

These systems & teams usually come together in delivering a product or service that directly impacts a customer (end user). Typically launching a major new product (or platform, say for example a new internet product like a streaming app for video on demand) will impact at least all these systems. To do so, a project is set up as a program delivery initiative that will call for the co-ordination of all systems coming together in delivering the new product or feature to market. So a program team would usually be setup to manage this execution and delivery. Typically a program manager would be appointed to manage the full end-to-end delivery, which is not only the technology arm, but also the wider business streams for delivering product to market (marketing, customer care, sales, training, retention, communications, legal & regulatory). Sometimes, the overall program manager is supported by an end-to-end technical program manager, but this is not always the case. More often than not, the overall program manager assumes co-ordination of the technology ecosystem as well. For now though, I use program manager to either mean end-to-end technical program manager or overall program manager interchangeably.

The need for an End-to-End Solutions Architect

The picture below illustrates the positioning for a dedicated role of E2E Solution Architect to a project or program of work:

Just as you would appoint an end-to-end project / program manager to the role of maintaining the coherency of the overall delivery project, so too should you assign an end-to-end solution architect role, to maintain the integrity and coherency of the overall technical solution design. This is the crux of my proposition. Related to architecture is a close relative called end-to-end systems integrator role, I've touched on systems integration topic on a previous post called Worlds of System Integration, so will not discuss integration in this post. Related to end-to-end integration is testing, in my past experience, integration implied testing or QA, but as I later learnt on coming to back to South Africa, most companies still see QA as a separate activity, so I have another post that talks to the Worlds of QA testing.

Why?

Because it makes running a project so much simpler! 

When I work with an E2E architect, I use it as a vital supporting pillar of the project. The E2E architect will take care to understand the business or product requirements from the business owner, works with all the respective technology domain experts (usually the assigned system architects) on mapping out a solution architecture, defining the new technology dictionary and model (if needed), highlights the system building blocks and supporting components that would be impacted, agrees on high level technical requirements from such systems, as well as important integration points, technology risk assessment, along with unearthing required non-functional requirements (performance, stability, redundancy, etc.) that would be needed for a complete solution. All of this is kept high-level, with just enough information to allow the project team to shape and scope the project, as well as prepare the technical teams of design constraints to think about. All of this is done in the early stages of shaping and scoping a project, has proven in my experience to be absolutely vital in a successful project outcome.

To be assigned an E2E Solution Architect to a project is no small feat. The expectations are quite high indeed. The role not only requires a sound grasp of technical concepts, but also mandates a personality that is comfortable with extreme forms of collaboration, managing and dealing with diverse stakeholders, personalities and egos (don't forget egos - tech guys can be a difficult bunch of people with huge egos), a strong suite of leadership skills, self-discipline, self motivation and the ability to work with ambiguity, a responsible attitude to self-management of tasks (without depending on a project manager to co-ordinate every meeting for example). Added to that, the E2E Architect must have excellent communication skills, demonstrating both in written and verbal form, the ability not only to handle technical communications, but also be the person to translate to business stakeholders in a simple, non-technical manner.

I rely on this architect to also grasp technical and architectural issues that might come up in delivery, and be able to provide solutions and advise on ideas and proposals to manage any impediments on the overall solution provisioning.

Why can't you just feed the business requirements to each division?

The short answer is the risk of lack of coherency of an overarching, end-to-end solution design. The absence of an E2E architect acting as the gatekeeper for maintaining overall integrity and coherency of the business requirements and related solution design, runs the risk of each division designing and implementing fairly independent solutions, leading to fragmentation, increased integration and last-minute rework to get a coherent solution delivered. This also leads to a system implemented without foresight, lacking the vision or with the end in mind. An E2E architect would fill this void, save a lot of time and energy in putting all the pieces of the puzzle together. 

Though not impossible to complete a project without the E2E architect, it is often through a lot of last minute co-ordination efforts of a project management team, or some efforts of a few technical heroes coming together, taking collective ownership of the problem. Generally these units have other work and projects going on concurrently, where focus on a single project is difficult to achieve. If the environment of very open collaboration and team work, where there aren't really any silo-mentality, then yeah, it's possible. But the reality is that in most organisations, silos exist, collaboration is not the norm, and the overhead of a project management team coordinating these activities is too high, let alone the implied technical knowledge of these project managers to make this a worthwhile activity.

This reminds me of the story about Christopher Wren, the architect responsible for rebuilding St. Paul's Cathedral after the Great Fire of London. Wren was walking the length of the partially rebuilt cathedral when he asked three bricklayers what they were doing. The first bricklayer responded, "I'm working." The second said, "I'm building a wall.". The third paused, looked up, and then said, "I'm building a cathedral to the Almighty."**

How many teams fully appreciate the work they do in the context of the end-to-end ecosystem? It is not expected every team have this kind of vision, it would be great if they could all see the big picture and be visionary, but in reality they're not - and there's nothing wrong with that. The instructive part of Wren's story is that he didn't come up with a sense of purpose himself and pound the vision into everyone's head. Each bricklayer cared about something different, even though all three were working on the same thing. Wren's role was to listen, to recognise the significance of what he heard, and to create working conditions that allowed everyone to find meaning in their own way.

In the same way that Wren appreciated the vision, the E2E architect plays the same, working with, collaborating, listening and negotiating with individual teams. Feeding a business requirements spec to each technical division independently, without a golden thread joining everything together, is not the most effective way of maintaining coherency.

[Next section: Why a solution architect and not a technical project manager instead?...]

The Project Team as a Relay Team

The analogy of a relay race team has been used a few times in project management. It is a great analogy for project teams because it reflects the passing of the baton, from one player to the next, after each player completing a set distance, just as with projects consisting of multiple teams dependent on each other for the ultimate success of completing the project. The passing of the baton, the execution and seamless delivery from handover-to-pickup-and-sprint more often than not (assuming the runners are the same) will account for a win or a lose the race moment.

What triggered me to write this post is not the relay race applied to a project team responsible for execution (typical critical chain analogy of passing information to teams waiting, managing the interfaces so that it's clear, etc.), but rather I wanted to focus more on the actual PMO (project management office) or project management team itself (typically the group of project managers assigned to the project). Where there is a large endeavour, a project of more than 12 months up to say 36 months, those long running projects that have a team of project managers responsible for overall delivery, then with this context too, I believe the relay race analogy is quite apt and relevant. It becomes a relay race for project managers: the baton is passed on to a new project manager, with each passing of the baton, the project receives a burst of new energy, enthusiasm, keeping the project alive. For long-term projects, I believe it is vital to renew the energy by bringing in new people often replenishes the project, breathes new life and momentum...as long as you choose wisely and get the timing just right.

If you're leading a PMO (Project Management Office), you will have at your disposal program managers, project managers & project administrators - all of varying degrees of skills, experiences, competencies, strengths and weaknesses.  Similarly a program manager of a large project, will have have access to a similar compliment of people, making up the project team. Whether you're leading a PMO or a running a program, as the senior project professional, you assume the role of project leader. As a project leader, you create your project management team and are responsible for the life of the team.

Project management teams are no different to other teams. They also go through the stages of development: Forming, Storming, Norming and Performing. They too have their own challenges, just like any other team would. I believe that as a project leader, it is important to keep abreast of your project management team's competencies, you need to be able to gauge the energy of the team and tell when it's time to pass on the baton. Even as a project leader yourself, you might have to pass on the baton to another project leader to see the project through to completion. And I don't see this passing of the baton as a reflection of failure on the part of the manager, it is just a fact of reality. A true leader will know when to move on instead of causing harm to his followers. A project manager should know when its time to pass the baton on to another project manager for the best interest of the project.

On long-term projects, keeping the team in tact can be challenging. Depending how far along the project is in execution, you run the risk of the work becoming routine, rote and uninteresting. Once things become mechanical, which is not a bad thing for the project, but for the human being serving the role as project manager, it might start to get tedious. Of course, I'm not passing a value judgement on all project managers, everyone is different - some people love staying the course, from start-to-finish, must-see-it-deliver mindset, whilst others might want to leave just as the corner is being turned with the project close-to-completion, and all downhill from there.

Examples of Relay Race for Project Management Teams

Looking at the classic PMBOK stages for project life-cycle: Initiation, Planning, Execution, Monitoring & Control and Closure, or, looking at a more broader stages of project leadership: Shaping & Scoping, Start-up, Delivery & Closure - what if your project managers mastered a particular stage of the life-cycle? 

With a specialist PM per stage of life-cycle, you play to people's strengths. As much as people might want you to believe that a project manager should be versatile and be proficient with all stages of the project life cycle (heck, that's why there's certification right?) - it has been my experience that this is not the case.

There are some people that are really good at starting projects but not finishing. Some are great at big picture strategy, scoping, shaping and starting-up, but lose interest when it comes to execution and delivery. Whilst some people are great at execution, monitoring and control, but lack the depth, breadth and wisdom of big picture envisioning to dream up a decent project charter, engage in meaningful dialogue with stakeholders and visualising the strategy. Some people are great at detailed mapping of project plans in Microsoft Project, detailed status reporting and tracking but fail to see the big picture. Some people have so much energy to close out the last phase of delivery, but find themselves at a loss when starting a project on a blank piece of paper. Some people experience fatigue mid-way through the project, others are sprinters who love the stress of the last mile.

Yet, when all these people form part of a bigger project team (the project relay team), magic happens. Each PM plays to his/her strength during the project life-cycle, handing over as needed, just-in-time before the project becomes a burden to complete...the project heartbeat is maintained and can live to completion.

So what am I saying then, really?

In the past I have handed over my projects as if I was handing over the baton in a relay race. I saw my passing the baton to another project manager as a vital component to the success of the project. A runner can not run the relay race alone, so in the same vain, for large projects that demand a level of endurance of project management execution, you must set yourself up with a project management team that would be capable of passing on the baton...I have in the past, introduced new project managers into my team specifically to introduce "new blood" and new energy as way to prevent project fatigue (it works)...

Past Experience

I once worked on a very large project that lasted about five years, with me joining the project in the second year. The project was one of the best projects I've worked on, it shaped me and thought me the hidden gems of project management that no PMBOK book or certification course will teach you. We were a team of five project managers based in UK, with peer PMs placed in France, India & Israel. Overall the full project team was between 350-500 people. We had a customer that was ruthless and very demanding, the customer also had a complement of 5 PMs in the UK.  

Ship of State Metaphor

I recently completed Jim Benson's book "Why Limit WIP: We are Drowning in Work". It's a simple, straightforward read, in the form of a story around typical life pressures in a corporate running multiple projects, all with the same sense of urgency, but teams not actually shipping any product (that is, completing any work product and releasing to market).

Jim introduces a metaphor called the Ship of State, as a way to help the team's product and project managers navigate through the uncertainty, thus allowing the team freedom to decide (empowered) what is safe and within their control to make decisions and others where the team still need to act, but still keep the stakeholders informed of their thinking. The scene is around product features for roadmap, which I thought quite powerful and useful - with a much wider application than just roadmapping features.

So I created this little poster that captures the essence of the metaphor. Does it makes sense?
Think about what your ship of state would look like (personal or professional)....

Ship of State

Signs of Stress every Project Professional should know

When you're working on projects you will experience many challenges: from working on multiple, often conflicting and ambiguous priorities, multiple streams of work (tasks, work packages, etc.) as well as interacting with many different types of (difficult) people, from different cultures, behaviours to different languages spoken. Your customers (stakeholders, client, sponsors) will vary in quality, more often than not applying pressure for their work getting done (because more than likely its linked to some kind of personal objective / business reward). This pressure is usually passed down to the project team members assigned. With the focus on delivery & timeline pressures, the project manager is often forced to multitask, expecting the same from project team members who often have the challenge of juggling between between project and non-project work, multi-project work (generally people are assigned to more than one project at a time) and not forgetting people's own personal/life (family, health, etc.) challenges thrown into the mix.

All of this can become too much, and as a project professional (project manager), who's primary responsibility (in my humble opinion) is to ensure his people are led, directed, guided, coached through the implementation phase of the project thus meeting expectations of the customer and coming away intact, that it behoves the project manager to be aware of the common signs and symptoms of stress. After all, we work with human beings, not machines that are oblivious to mood swings, emotional problems and simple pleasures - so being mindful of your team members state-of-mind, as well as your own -- and taking time to truly pause and reflect, adjusting your behaviour as a project manager can go a long way to not only improving your work relationships, but also can help with the the successful outcome of your project implementation.

The American Institute of Stress (AIS) stated that the term "stress" was coined by Dr. Hans Seyle in 1936, who defined it as a "the non-specific response of the body to any demand for change". He sometimes defined it as "the rate of wear and tear on the body".

Here are some fifty common signs and symptoms of stress from the AIS. Look out for these in your own life as well as the people you work with.

• Frequent headaches, jaw clenching or pain
• Gritting, grinding teeth
• Stuttering or stammering
• Tremors, trembling of lips, hands
• Neck ache, back pain, muscle spasms
• Light-headedness, faintness, dizziness
• Ringing, buzzing or "popping" sounds
• Frequent blushing, sweating
• Cold or sweaty hands, feet
• Dry mouth, problems swallowing
• Frequent colds, infections, herpes sores
• Rashes, itching, hives, goose bumps
• Unexplained or frequent allergy attacks
• Heartburn, stomach pain, nausea
• Excess belching, flatulence
• Constipation, diarrhoea
• Difficulty breathing, sighing
• Sudden attacks of panic
• Chest pain, palpitations
• Frequent urination
• Poor sexual desire or performance
• Excess anxiety, worry, guilt, nervousness
• Increased anger, frustration, hostility
• Depression, frequent or wild mood swings
• Increased or decreased appetite

• Insomnia, nightmares, disturbing dreams
• Difficulty concentrating, racing thoughts
• Trouble learning new information
• Forgetfulness, disorganisation, confusion
• Difficulty in making decisions
• Feeling overloaded or overwhelmed
• Frequent crying spells or suicidal thoughts
• Feelings of loneliness or worthlesness
• Little interest in appearance, punctuality
• Nervous habits, fidgeting, foot-tapping
• Increased frustration, irritability, edginess
• Overreaction to petty annoyances
• Increased number of minor accidents
• Obsessive or compulsive behaviour
• Reduced work efficiency or productivity
• Lies or excuses to cover up poor work
• Rapid or mumbled speech
• Excessive defensiveness or suspiciousness
• Problems in communication or sharing
• Social withdrawal and isolation
• Constant tiredness, weakness, fatigue
• Frequent use of over-the-counter drugs
• Weight gain or loss without diet
• Increased smoking, alcohol or drug use
• Excessive gambling or impulse buying

Check out this Human Function Curve by Nixon in 1979, that illustrates the generally accepted view of the effect of stress on worker productivity. It is entirely personal and shows that each person has their own individual limits for stress - there are good stresses and bad ones. Zero stress = Zero performance - interesting.

Human performance peaks at modest amounts of stress. (Source: Nixon, p: Practitioner 1979)

Credits / Reference Material
I came across this topic from this book, Chapter 2 on The Human Behaviour Problem as Root Cause: Multitasking from Critical Chain Project Management by Leach

The Immutable Laws of Project Management

I came across this classic list a while back and was reminded recently about it in Critical Chain Project Management by Leach, so I thought it useful to store as reference (yes, it's already online, but I actually enjoy writing things down as a way to reinforcing my memory).

I can personally identify with all these laws in my history of working on projects, how does your experience compare :-)

The Immutable Laws of Project Management

LAW 1

No major project ever completes on time, within budget, with the same staff that started it, and the project does not do what it supposed to do. It is highly unlikely that yours will be the first.

Corollary 1: The benefits will be smaller than initially estimated, if they made estimates at all.

Corollary 2: The system finally installed will be late, and will not do what it is supposed to do.

Corollary 3: It will cost more but will be technically successful.

LAW 2

One advantage of fuzzy project objectives is that they let you avoid embarrassment in estimating the corresponding costs.

LAW 3

The effort required correcting a project that is off course increases geometrically with time.

Corollary 1: The longer you wait the harder it gets.

Corollary 2: If you wait until the project is completed, it is too late.

Corollary 3: Do it now regardless of the embarrassment.

LAW 4

Everyone else understands the project purpose statement you wrote differently.

Corollary 1: If you explain the purpose so clearly that no one could possibly misunderstand, someone will.

Corollary 2: If you do something that you are sure will meet everyone's approval, someone will not like it.

LAW 5

Measurable benefits are real. Intangible benefits are not measurable, thus intangible benefits are not real.

Corollary 1: Intangible benefits are real if you can prove that they are real.

LAW 6

Anyone who can work effectively on a project part-time certainly does not have enough to do now.

Corollary 1: If a boss will not give a worker a full-time job, you shouldn't either.

Corollary 2: If the project participant has a time conflict, the work given by the full-time boss will not suffer.

LAW 7

The greater the project's technical complexity, the less you need a technician to manage it.

Corollary 1: Get the best manager you can. The manager will get the technicians.

Corollary 2: The reverse of corollary 1 is almost never true.

LAW 8

A carelessly planned project will take three times longer to complete than expected. A carefully planned project will take twice as long.

Corollary 1: If nothing can possibly go wrong, it will anyway.

LAW 9

When the project is going well, something will go wrong.

Corollary 1: When things cannot get any worse, they will.

Corollary 2: When things appear to be going better, you have overlooked something.

LAW 10

Project teams detest weekly progress reporting because it so vividly manifests their lack of progress.

LAW 11

Projects progress rapidly until they are 90 percent complete. Then they remain 90 percent complete forever.

LAW 12

If project content is allowed to change freely, the rate of change will exceed the rate of progress.

LAW 13

If the user does not believe in the system, a parallel system will be developed. Neither system will work very well.

LAW 14

Benefits achieved are a function of the thoroughness of the post-audit check.

Corollary 1: The prospect of an independent post-audit provides the project team with a powerful incentive to deliver a good system on schedule within budget.

LAW 15

No law is immutable.

My library on Project Management

Here is a live list of all the project management books I own in my personal library. I have read every one from cover to cover. Each one has helped me in some way or the other in mastering the art and skill in project management, that I now find myself less interested in the detail of project management, but rather more interested in the project leadership aspects of the domain: setting strategy, starting-up and shaping projects, forget date-drive tracking and focus on building commitment instead, building relationships, program report visualisation (one page project manager reports, Toyota A3, etc.) & simplification (cut-down meetings, reduce waste, manage work-in-process), running & facilitating workshops (brainstorming, scoping, discovery, pre-mortems, retrospectives), organisational change & transformation, playing coach, guide, mentor and advisor to PMOs & Execs.

This list is in no particular order but towards the bottom end are the most recently read books. Not sure where all the icons disappeared to, but the links should work.

Enterprise Agility Workshop

I recently held a workshop with senior management (general managers and executives) of a large enterprise company on agile methods. In this post I share the framework that helped me execute the workshop, sharing the experience and points for reflection. 

The situation with this client is a typical enterprise organisation structure, divided into broad areas of "Business" and "Technology". Divisions within the "Business" include Customer Care Operations, Marketing, Finance and a PMO. Divisions within "Technology" included IT Business Systems, Digital Media Product Development & Consumer Technology. Strategy is a separate division altogether. Added to this mix is the Technology Division supports multiple business units, with each business unit sharing similar (but unique) operational entities. The tech divisions were also unique in that each applied their own flavours of delivery: two were agile (but had different implementations of methods like scrum / kanban), whilst the third implements a hybrid waterfall / iterative life-cycle. And lastly, these three tech divisions had their own flavour of delivery PMOs (so count that as four PMOs in total, plus another PMO for BI/Analytics group - so that's five PMOs!).

The business people's request was basically:

We work with technology teams that are using this thing called Agile. What is it? Can we have a workshop to review agile methods, to decide whether / what / if the full enterprise needs to do / change to become more agile? How can we deliver faster? How can we get technology teams to respond faster, given that we in business operations can't move as fast as technology?

I was doubtful to say the least, because to me, timing was everything. The dust hadn't settled yet due to recent (and ongoing) organisational re-structures within both business and technology divisions, so I was hesitant this workshop would not add much value. Anyway, the client insisted the workshop happen, so I had to make it happen.

Was the workshop a success? Well, my client would argue yes, it was a success and it's great that we made a start.

Did the workshop run as I expected? No, what I had in mind (see mind map), what I planned for and what actually transpired did not fully meet my expectations, still there were some lessons learnt, and validation of my ideas & experiments are useful, hence I decided to share the framework publicly.

How to frame the workshop?

My mindmap design for the workshop

This picture is the mind map I used as a guide to planning the workshop. I applied my RAGE model as a guide, looking at:

• Reality - I needed to understand the current reality of the stakeholders, in terms of their knowledge and experiences with agile methods?
• Aspirations - Wanted to understand what problems they wanted to solve?
• Goals - How could I run the workshop to address some of the stakeholders goals?
• Expectations - What were these guys expecting as an output from the workshop?

On Project Management

In the last couple of years, I've had people approach me from different areas (technical and non-technical) to teach about project and program management. I've had some senior management ask me to guide project managers (that were close to being fired that needed an intervention to turn them around), engineers seeking guidance on how to get into project management, and heads of PMOs tell their people to shadow me to learn how "Muhammad does it", so much so, that most recently, most of my style of project documents, reports & ways-of-managing-meetings have formed the basis of "how we should do things here" templates. This year, I was asked to teach a course and was even offered a potential future coaching opportunity to help a PMO reach their desired levels of performance (which plays nicely to my aspirations of improved life-work balance and creating more time for myself, like working 3-day weeks).

This might sound like great feedback, something to be proud of, and a rather nice side effect of the work that I have come to "just do" automatically. I had no ulterior motives for recognition and reward. I never once professed to be a grand professional project manager.  Heck, I am not even certified (even though I've been on training courses and I am quite well read), I don't even promote PMP / PRINCE2 / Agile certifications & methodologies, and I've hardly used MS Project to run projects - and here are people who already have all the certifications in place (and arguably more proficient with project tools like MS Project), coming to me, asking for guidance and to be taught!! 

In truth, this recognition (and sometimes public endorsements) makes me more uncomfortable to say the least and has increased my own self-awareness, because I'm actually quite acutely aware of my own limitations. What is it that my customers see in my work?? Do they realise I'm not even currently a certified PM?? How can I help transmit what I've learnt in my experiences (acquired wisdom & intuition) in project management, that people don't already know, that they wouldn't already have picked up in PMBOK certification courses anyway? 

Recently I completed Any Hunt's "Pragmatic Thinking & Learning", where I came across the Dreyfus Model; and earlier this year, I read Donnie MacNicol's "Project Leadership" which made me realise that I may just be at the level of Expert/Mastery (Project Leader) skill level on the Dreyfus model for most (but not all) of the skills for project & program management. In a future post I will share my own PM-skills diagnostic when viewed according to the Dreyfus model. This will be a useful self-discovery exercise especially after watching a talk on Ego is the Enemy by Ryan Holiday.

So as an experiment, I decided to create a rough mind map of my own PM Knowledge-base. When I start a project, what framework do I use that helps me navigate the project minefield? So I created the picture below - a very rough dump from memory. This could potentially serve as a rough outline of a coaching course I could do for project management. If I were to write a training plan, how would I structure it? If I were running a PMO, what would I focus on? I could just about write a blog post on each of the topics (and over time, I could have training material emerge, who knows!).

My PM Mind Map

Rough Mind Map

My PM Knowledge Base

Whilst I have to date, kept away from acquiring a formal PM certification (see this post that explains my reasoning to shy away from certification), I read a number  of books and material on the subject. Below is my library that has helped me in my quest to master the subject and sharpen my toolbox. This list is in no particular order, although each one has inspired me in some way and has had a direct influence into how I apply my knowledge in applying my project management roles (I've got another five more currently reading, the list will update as I finish more in future).

To manage software teams, take a page out of the baker of breads

Software management metaphor - Another one of those "This might not work" posts...

Last night I woke up from a deep sleep, to the sounds of the howling wind outside, the tatter-tatter of light scattered rain hitting the window, whooshing branches of the garden palm tree against the roof & telephone cable, at about one in the morning, and the sounds of an indecisive impending thunderstorm about to break - when a thought came to me: that managing software teams is just like being a baker who bakes bread! 

And if you're going to coach software teams, you won't do a great job unless you've been through a few projects yourself, in say maybe three different products...just like a baker should never profess to be a a true baker of breads if he/she only knows of just one type of bread :-)

So let's build on this metaphor

There are no doubt a wide variety of breads, over two hundred according to wikipedia. Each bread appears to have its its own unique characteristics, not just from outward appearances, but also sometimes, unique ingredients as well. 

Though most breads may share a common pool of ingredients, they will vary in terms of process & methods.  Some doughs (infrastructure code perhaps or engineering methods?) must be repeatedly pounded,  some need to reach a different points of elasticity, some need varying amounts of time to soak, just in preparation time, and some might be best served a day later. 

Some breads need a tender touch, care and extra attention, whilst some breads are rough, solid and can take on a few dents and bruises here and there. Either way, the baker understands that balance and care are needed to get the best bake out of the ingredients, methods and process - just enough and not forgetting, the baker's intuition, experiential wisdom all play a huge part into what makes a baker of breads, a great baker of breads...

The baker of breads is no doubt expert, finely attuned to the methods and processes that must be applied to each bread to get the desired result: beautifully baked, well worth the time, effort, energy and most of the time, patience.

Any shortcuts taken, or hastily applying a different method based on some other bread type could result in failure, or perhaps a mutation of sorts. The end result is likely not a very good bread, far from edible.

In pretty much the same way, a software manager (coach, consultant, etc.) needs to approach each software team with care, take time to understand its own unique character, culture and drive for success, applying possibly unique methods to "bake" the teams to reach their desired goals and outcomes. And this outcome in my view, is one of delivering value, keeping customers happy.

So to end the metaphor, a software manager must become a master chef, a baker of breads. Understand each bread is unique, invest in appreciating this uniqueness which may need you to change your own behaviours and biases. 

And revel in the the taste of variety...

Then I went back to sleep...

The PayTV Platform VS Product Debate

This post has been on my TODO list for four years. It started as trying to clarify the role of the STB: Is it a Platform, or is it a Product?? I now feel this debate needs to be extended beyond the STB domain, and instead focus on the bigger picture - the end-to-end video technology stack. And in order to do this, one has to start right at the beginning - understanding the future design of a PayTV business...This blog post is a work in progress, my thoughts are not fully structured and far from complete...I needed to get this thing off my Trello TODO list because it was starting to burn a hole in my screen, so here goes...

The topic of what drives innovation in software companies in terms of understanding the differences between a Product versus a Platform is not a new one. It has been discussed since the early 90s in lead up to the evolution of PC Operating Systems & Applications, early 2000s on the dawn of the Internet age, mid-2000s on the rise of mobile platforms and the resurgence of Apple. Citing a few articles that discusses this topic of Platform/Products, by Michael Cusumano, a leading expert on the subject:

• The Evolution of Platform Thinking
• The Platform Leader's Dilemma
• Platforms and Services: Understanding the Resurgence of Apple

However, in the context of Digital TV, Pay TV or what the market is now calling "Video Entertainment", I feel not much has been written about this subject. This is probably because of the largely historical nature of these technology & architecture platforms being proprietary, in what has been quite a much-guarded and competitive landscape by technology vendors traditionally in the Set Top Box middleware space.

I believe the very same challenges that existed twenty years ago in the PC-world are really no different to the challenges Pay TV software systems face today. Whilst Pay TV exists to generate as much revenue from its subscribers as much as possible (one really can't argue with that bottom-line), one cannot ignore the fact that there is an enormous amount of software systems that power the business (consumer devices, broadcast systems, security & encryption software, billing & subscriber management systems, and more recently internet-backend services that deliver digital services on additional devices other than just set top boxes) so much so, that one could even argue that Pay TV is fundamentally, a software technology-driven business - and since this is pretty much the reality of today, then the topic of Product v Platforms in PayTV is all the more relevant!

Historically, the medium of consumption of PayTV, was through a device called a Set Top Box (STB). A piece of hardware that allowed a customer access to the content broadcast. The STB offered rudimentary user interface (an application / electronic program guide) that primarily allowed users to find content to watch - and this basic use case can still be considered the primary use case for PayTV, despite the bells and whistles that come with flashy graphics. The interface exists to allow users to find and watch content, period.

I believe the STB, in terms of software architecture, has to evolve from the once historic notion of being viewed as a standalone product, to instead becoming part a platform ecosystem, just like any other modern operating system (iOS, Android, etc.) that exposes a set of capabilities that allows for re-use of software components across devices. That, with the increasing convergence of mobile/internet/broadcast, the STB can no longer be considered its own island, with its own unique software stack (some might argue that these stacks are archaic), somewhat silo'ed & isolated from more modern technologies as in the case of platform software driving pretty much the mobile (smartphone / tablet) devices.

I have worked in the STB world for pretty much most of my career. I've always felt that we were really reinventing software systems, architectures and design patterns that was pretty much known since the sixties (really). In the last eight years, we started moving to the converged world, merging broadcast-and-internet TV, and in doing so, the constraints of the STB world start to reveal itself, especially when it came to inter-networking features, light-weight components and services-based design patterns and the challenge of essentially re-using software components across different devices. I've seen companies and teams struggle to adapt to this new challenge, especially when it came to the topic of truly understanding what it means for differentiating a Product or a Platform?

Is the Set Top Box a Product, or is it a Platform??

An example STB Platform

I believe the days of the STB as a unique device for viewing content, the primary means of interaction, and the constraint of being stuck in the world of broadcast TV - are over.

Customers don't care what a PayTV operator labels & markets its device as. The STB is simply, a means to an end - a thing that lets you connect your TV to access a world of content provided by a PayTV operator through a transport medium (satellite, terrestrial, broadband, whatever). And that in the connected world of the internet, customers expect to access the same experience on any mobile device (because it is possible and it's expected).

So initially, in isolation, just looking at the STB alone - I view the STB as providing platform software, just like iOS or Android.
From a hardware perspective, the STB device hardware too, is also a platform that allows the PayTV operator to incrementally add features over time. The hardware usually shares future-looking capabilities that STB software can realise over a period of time (usually 5-7 years, but this time is being reduced to more like 3-5 years shelf life).

This may sound like commonsense, because it is what consumers are used to with more modern  iOS & Android platforms, right? Yes, but in the world of PayTV, I've seen how technology implementations can go wrong, costing PayTV operators lots of time, money and energy, lost opportunities, lose market share, etc - due to not taking time to properly assess the nature of their products and services as well as the underlying technology ecosystem needed not only to satisfy their current business needs, but also the systems to power & drive future growth (at little cost, avoiding long development cycles, re-work and silo'ed ring-fenced deployments making maintenance a nightmare).

I also believe that we need to go further than just thinking in the STB-world - we need to think about a platform world, a world of re-use. The same applications and user experience must exist on all devices, regardless of technology domain. If the customer is expecting this unified seamless experience, in the same way the software components need to be shared across the architecture domains. I don't expect there to be separate application development teams per device. What usually happens is a PayTV operator has separate vendors, with their own stacks, a development team for STB, another development team for iOS, another team for Android, another team for PC/Web - all implementing pretty much the same thing. And similarly, separate infrastructure services teams (broadcast headend, internet online backed teams) usually fragmented, working in silos, often with duplication of services.

So the question for me has evolved: it is no longer about the STB being a product or a platform. It is about the End-To-End PayTV Technology Platform - how should a Video Technology Ecosystem be structured today?? Out with the old, in with the new is what I say ;-)

Why understand the difference between a Platform & Product?

Reflections on my career in Software Engineering & Management

I was going to keep this post in my own internal reflections journal, but then decided not to, and instead, take a leap and make this public, since it may be of use to people who find themselves in a similar situation as I did, that is - the choice of branching out from software development path into the project management path.

So in sharing my experience, I hope it could help and benefit others, seeing that recently I've been approached by a few engineers about switching from a technical path into a project management path, which is the path I've been exposed to - and a path, that I myself am now, again find myself at a juncture, where I'm considering about what to do next(!).

Courtesy (link)

I am by nature, what you would call a Switcher (previous company even made a "switcher video" for people who moved around the organisation). It is probably down to my wiring, my upbringing & challenges growing up, experience of reality and my internal motivations that drives this behaviour - my own biases - that kick in and call for a change of some sort.  It is a state of restlessness that can only be resolved by a change, which I now find myself in, having given myself till March 2017 to implement my next transition.

The rest of the post is set as a series of Questions & Answer session that I had recently with myself, as part of my own introspection, as I took a long walk in the park, on a beautiful winter morning, just after sunrise, and did some soul-searching...I was the only walker, so I had a verbal conversation with myself:

Why did you choose a career in Software?
Why did you switch within software engineering roles?
Would you recommend software engineers to switch domains?
Why did you leave Software Coding and switch to Project Management & not pursue a path in Software Management?
What happens to your technical skills, are they still sharp?
Do you think it mandatory to get a PM Certification?
Do you regret the choice you made into Project Management?
Do you believe you've met your aspirations from Project Management path, looking back from where you started?
Given your PM journey, do you still consider yourself a Project Manager?
Given your experience, what next lies for you in the path of Project Management Career? Where to from here?
So what is this thing called "Project Leadership" then?
Where to from Here? After Project Leadership, what's next?

Consulting, Star Trek Prime Directive & My Simple Rules

DISCLAIMER: This is another idea or concept that just might not work, or people might find it a bit edgy...but it's been on my mind of late, and so I needed an outlet, hence this post, likely to need a few iterations :-)

In Star Trek, there is this philosophy called the Prime Directive, where an advanced civilisation, when either coming into contact with, or observing from afar, a culture or civilisation that is less advanced, or, the culture is at an early stage of growth / innovation / expansion, the rule is one of non-interference. Interfering or exposing advanced technology (or a culture) to a somewhat less-advanced civilisation might end up causing more harm-than-good, so it's better to stay away (as a right of non-imposition / interference).

Can this concept be applied to consulting, or even your workspace in general?

Star Trek
As the right of each sentient species to live in accordance with its normal cultural evolution is considered sacred, no Star Fleet personnel may interfere with the normal and healthy development of alien life and culture. Such interference includes introducing superior knowledge, strength, or technology to a world whose society is incapable of handling such advantages wisely. Star Fleet personnel may not violate this Prime Directive, even to save their lives and/or their ship, unless they are acting to right an earlier violation or an accidental contamination of said culture. This directive takes precedence over any and all other considerations, and carries with it the highest moral obligation

My Own Prime Directive (Simple Rules)

I believe some parts of this philosophy can be applied to the subject of consulting, coaching or projects that touch on change & transformation, for example: agile-transformation, or even the reverse, going back from "wrong agile" to a structured, predictable waterfall, classic command-control-central-planning methods...the situation in my context: coming from a world of advanced software engineering into a world just starting out, without having an actual mandate for intervening on changing process & methods (even though you know there is a better way)...or in the project world, how to work with people still entrenched in methodology dogma, instead of seeing projects as a people leadership activity, run by conversations & commitments and less so on Gantt-chart-style, date-status-checker-are-you-done-yet project management...

Being a consultant, at least in my experience, you need to have one or more prime directives of your own, some simple rules to guide you along a path that not only protects you as a professional (as well as a person / individual), but more importantly protects the clients (civilisations) you encounter during your formal engagements, including adhoc interactions & connections.

You could say I've been a consultant for the last five years, even though from a job title front, it is going on for 150 weeks and counting, nearing the three year mark. Before returning to South Africa, I had worked for international companies that specialised in Software & Systems Design & Engineering. I had the privilege to work with a few great teams, engineers, managers and leaders where I learnt the arts and secrets to some fairly sound, tried-and-tested Software Development & Project Management methods, including large-scale agile frameworks (which I've written about previously). Leaving the UK I'd just come off one of the largest, and most intense projects in my career to date (read here) - it is the kind of project that essentially kick-starts your career into consulting, it was my Everest where I knew instinctively that that project was as good-as-it-gets, and the probability of experiencing another similar monumental project in my future was going to be pretty low...

So when I started with my next project going back five-years ago, the landscape of the company, the product roadmap & projects portfolio was almost a copy-and-paste of my last project but tuned down by a factor of say 20 notches or so. I saw that as an opportunity to leverage the wins (and learn from the pain-points) of my Everest project, looking forward to create something similar but evolved...

It turned out it wasn't going to be that straightforward in reality...this particular civilisation was only just starting out, so I had to be mindful of the state & maturity level (new team, new to agile, new everything) just as when our Star Trek Explorers come into contact with less advanced civilisations and need to reference the Prime Directive. And the role I played wasn't grand divisional manager, but a role limited to program delivery (leaving the technical & rest of development processes in the hands of the respective managers). Even though I had come from a world of great industry, here I was faced with the challenge of working in a world just starting out...the choices:

I could go in all gung-ho guns-blazing (I'm the professional, I'm experienced, I've got years of experience, what you're doing is so minor in comparison to my last project, just listen to me, I'm the Expert, You listen-and-follow-me, I'll fix your entire division up even if it's outside my world of Project Management, I'm a generalist, I've seen it all...), heavily & dogmatically prescribe a blue-print, cookie cutter process, and do what-it-takes to enforce (bulldoze-through) the adoption;

OR

I could pick and choose the core concepts to focus on (in-line with the organisation's state of development i.e. similar to how a civilisation has advanced technically/socially/culturally), that would incrementally lead to the organisation's goal (deliver product), but at the same time forge the road ahead on which their teams would grow, learn, develop & empowered to own the problem-space (allowing them to make mistakes along the way).

Tips on how to gracefully disagree

I am currently reading through the classic 1930's writings of Dale Carnegie's How to Win Friends and Influence People. Still a classic, and still pretty much relevant today, which struck me in the same awe as my earlier encounter with Elbert Hubbard's works. If you haven't read this book, please get a copy soon! 

I am quoting some tips from Part Three, Chapter One on how to keep a disagreement from becoming an argument (that Carnegie himself sourced from an article in Bits and Pieces, published by The Economics Press, Fairfield, N.J.):

Welcome the disagreement

Remember the slogan, "When two partners always agree, one of them is not necessary." If there is some point you haven't thought about, be thankful if it is brought to your attention. Perhaps this disagreement is your opportunity to be corrected before you make a serious mistake.

Distrust your first instinctive impression

Our first natural reaction in a disagreeable situation is to be defensive. Be careful. Keep calm and watch out for your first reaction. It may be you at your worst, not your best.

Control your temper

Remember, you can measure the size of a person by what makes him or her angry.

Listen first

Give your opponents a chance to talk. Let them finish. Do not resist, defend or debate. This only raises barriers. Try to build bridges of understanding. Don't build higher barriers of misunderstanding.

Look for areas of agreement

When you have heard your opponents out, dwell first on the points and areas on which you agree.

Be honest

Look for areas where you can admit error and say so. Apologise for your mistakes. It will help disarm your opponents and reduce defensiveness.

Promise to think over your opponent's ideas and study them carefully

And mean it. Your opponents may be right. It is a lot easier at this stage to agree to think about their points than to move rapidly ahead and find yourself in a position where your opponents can say: "We tried to tell you, but you wouldn't listen."

Thank your opponents sincerely for their interest

Anyone who takes the time to disagree with you is interested in the same things you are. Think of them as people who really want to help you, and you may turn your opponents into friends.

Postpone action to give both sides time to think through the problem

Suggest that a new meeting be held later that day or the next day, when all the facts may be brought to bear. In preparation for this meeting, ask yourself some hard questions: Could my opponents be right? Partly right? Is there truth or merit in their position or argument? Is my reaction one that will relieve the problem, or will it just relieve any frustration? Will my reaction drive my opponents further away or draw them closer to me? Will my reaction elevate the estimation good people have of me? Will I win or lose? What price will I have to pay if I win? If I am quiet about it, will the disagreement blow over? Is this difficult situation an opportunity for me?

The only way to get the best of an argument is to avoid it.

My RAGE Planning Template

In my previous post, I shared my RAGE model for personal planning. RAGE standing for Reality, Aspirations, Goals, Expectations. I described my journey as I went through my own introspection, splitting myself up into the many Personas I found myself involved in, and shared how I systematically made sense about my priorities and areas to focus on. As always, I tend to go over-the-top, I covered a lot of detail, which to me was quite valuable, but for others maybe not so :-))

The feedback received was quite encouraging to say the least, people suggested I dumb it down a bit, provide a template to focus on a more manageable (handful) of topics, the ranking matrix caught some interest as well. So in this post, I'm sharing a cut-down, generic template for anyone to use to make sense of just ten Personas. You can access the template here, available freely for download.

Template in a Nutshell

Template is an Excel document with the following sheets:

1. RAGE List - this is basically the main board. You select the type of persona (choose between Personal & Professional), Give a name for your Persona (e.g. I, as a...) & fill out your Reality, Aspirations, Goals & Expectations. The board will automatically calculate the rankings, and dish out a planning priority.
2. Persona Rankings - This is the crux of the exercise - for you to compare one persona against the others. Requires deep introspection - who are you really?? What is it that really excites you?? Which aspect of your life should you focus on more?? This is the persona ranking matrix.
3. Look-Ups - The hidden data behind the calculations. You wouldn't usually touch this, but if you wanted to weight things differently, you can attach your own numbers to the weightings.
4. Example Personas - I provide an example of generic persona types that you can use to get your own thinking going.

Master RAGE Board

Persona Ranking Matrix

Example Personas

If you end up downloading the template, and have experimented with it, OR you need some one-on-one help, please get in touch!

Introspection is worth it, you will be amazed at what you uncover...I hope you try this tool out!!!