Thursday, 1 August 2013

The Projects Manager as a Shepherd


It is now eight years and counting that I've been involved in managing Software & Systems Projects as Projects / Programme / Portfolio Manager, enough time I suppose, to have built up at least some experiences that might count as pearls of wisdom, that I could impart on fellow young Project Manager newbies entering the role; or to young engineers doubting the usefulness & effectiveness of the various Projects Manager roles.
I started off as an EIT (Engineer-in-Training), following the usual technical ladder reaching the point of Senior/Principal Engineer. I could have stayed on the technical path (I enjoyed writing code, wrote some really good code too [it's a great feeling when a consultant comes to you after your code has been in circulation for three years saying "your code is one of the most beautiful pieces of code I had to extend, it was really well written, a pleasure to maintain"]) but I always intended to learn everything about the Software business and so couldn't see myself inclined to writing code, debugging, doing maintenance, support or integration forever. I also did not want to become a traditional Line Manager that gets to look after lots of people (although I could) doing appraisals, managing performance and dealing with Administration & HR issues, not to mention Office Politicking. So I delved into Technical Project Management, just around the time that Agile/XP practices were gaining strength and coming of age.

I felt that Project Management touched on a variety of aspects of the business of Software, Management, Business, Execution & Delivery - so I wanted to experience it. The role includes managing stakeholders up and down the business, engaging with engineers directly, doing demos and exhibitions, dealing with customers and third parties, setting up contracts, commercials and strategic planning, interacting with sales/marketing and also contained (to my pleasant surprise) a lot of coaching, mentoring and up-skilling project team members -- so pretty much touching on all areas of the business, a little more exciting than being just a Software Development Manager IMHO...

Quite recently, a young graduate newbie once called me a Pseudo-Technical Manager, inferring to someone who has dabbled in Technical/Engineering and just wasn't cut-out for the Techie nitty-gritty stuff. A young Project Manager would have been outraged at this insult of this arrogant young-fool, child of the Y generation - challenging the new PM in the first week of the job! Alas, I just smiled at him for his passion in being an engineer and for his naivete in not understanding the bigger picture. I could have pointed this graduate software engineer to all the code I've written and products delivered that was light years ahead of the current company's portfolio - but instead I let it lay (He will grow in time, and besides, PMs have a thick skin - we don't get offended or take things personally)...

Projects Managers, whether they come from a Technical (Software Background) or not (Construction, Mining, Psychology, Finance), regardless of the new buzzwords that come and go, are here to stay because the role offers value. Plain-and-simple. Scrum Master, Product Owner, Product Manager or not, there is still a need for a role to provide the Map, a Path to get to the Destination, clearing the Path, removing Obstacles and ultimately Executing & Delivering the Project through its People. Although, having said that, I have been biased, perhaps a little prejudiced against Project Managers assigned to a Software/Systems Project that have really never experienced the art of Software/Systems Engineering before, first hand, in the trenches. That is, I used to say "If you ain't written code before and delivered real software products, then you're ain't managing my project". In the same vein, I was also not convinced that you can be a CTO or CEO of a Technical Organisation, having never been technical yourself (a post for another day...). But through my own personal growth I have come to work and appreciate a Projects Managers from variety of backgrounds, even those of whom have never written a line of code, deserving of my appreciation...

Coming back to point, a Projects Manager is a much needed (but sometimes undervalued) role in an organisation. One of my first PM mentors stressed upon me that a PM is really a Service Provider: PMs provide a service to the project team/engineers. That concept did indeed take some time to warm up with me, as will most PM newbies experience. The first inclination of a young PM is to be misled or disillusioned with power, that "with great power comes great responsibility", "I am Project Manager now, I call the shots, I drive the plan, crack the whip!", "I set my meetings around my calendar, people must just commit because I commit", etc, etc. On the other hand, another early mentor gave me this advice "If you ain't pissing people off, you're not doing your job as a PM. A PM asks difficult questions, follows-through, pisses people off. I measure your progress by the number of complaints coming back from people - you're being a hard-ass PM!"

Young Project Managers must start off slowly, beware of jumping into the role with the wrong attitude as if you're in charge, as a PM, you have to earn your stripes, work with and through people to gain respect, build relationships and ultimately become influential and a driver, through action and taking the lead. A PM must build up a level of Emotional Intelligence (something which I at first was wary of), understand the nuances of Cultural Dynamics and Neuroscience, working with and through people...Building relationships and effective communication skills are probably the two most important soft skills you will need as a PM...

So this Project-Manager-as-a-Service spiel stuck with me for a long time, and continues to do so today. Recently, I was playing with this metaphor that a Project Manager is really a Shepherd, as in a shepherd of a herd of livestock/cattle. I googled for a bit for similar metaphors but couldn't find anything that related to the message I had in my head. So I decided to write about it here as a first attempt, hopefully it will grow and mature over time depending on public feedback.

Tuesday, 30 July 2013

Agile Architecture - Roadworks Analogy

I've had some interesting, somewhat frustrating conversations recently, around the roles, responsibilities and expectations of a Systems Architect. Refer to a previous post on how I broke down the various architecture roles for Digital TV Systems Projects.

What triggered the recent discussions is around understanding how architecture fits in with the Agile process. Before people who think themselves Agile Aficionados (Agileficionados) singing praise that architecture can be done just-in-time, please remember the context which I refer to: Embedded Set-Top-Box or Backend Systems Engineering.

We are not in the business of writing web applications, smart phone apps, tablets, or any desktop application, or even a web site -- where these environments are usually proven, solid and stable that fosters rapid application development cycles.

Digital TV projects, especially Set-Top-Box projects are a little more complicated than iterating through web page developments, switching versions easily through redirecting URLs, eliciting real world customer feedback for alpha/beta sites or apps, etc. STB projects generally involved multiple vendors or software suppliers, each with its own development processes. Testing is often done in a limited lab environment, whilst real world customer feedback demands an end-to-end engineering system to be deployed in a live broadcasting environment (which is currently in active use, generating revenues for the PayTV operator, so engineers better be damn sure they're not going to disrupt business operations, etc).

So some STB project teams are indeed embracing Agile (or at least trying to be Agile in the context of their component-worlds). I have written about the difficulty of doing Agile in these projects that I'm not going to repeat here. How then does one deal with the concept of architecture in Agile? Do we stick to Just-in-time, just enough or do we embrace a little structure and discipline, in keeping with Mile-wide, Inch-thick view of the future, but not waste time with too futuristic features??

For Digital TV projects, I prefer the mile-wide, inch thick approach, where we're looking at least a year ahead into the future, to develop new features and enhancing the roadmap. This is especially true for long lead features, like Recommendations, Targeted Advertising, Home Networking, or even designing the next evolution of your Middleware or EPG. And I believe that Architecture, can still be done incrementally, in an Agile-manner, although with a little discipline called foresight and pragmatic proactivity. To support this picture, I created the Paving-the-Road analogy:

Saturday, 13 July 2013

What it takes to cut the mustard in STB Systems Integration

I have had this topic sitting on my backlog since I first activated this blog, now is a good time to start this topic off since recently it has become quite a topic of conversation in the workplace. I will refine this post over time, however, the first installation is just to share my thoughts around the role of STB Systems Integration, its importance and touch on the traits/skillsets as pre-requisites for the role, i.e. What I lookout for in people when hiring a Systems Integration Engineer.

First of all, one needs to understand the context of being a Systems Integrator. In the context of Set-Top-Box software, there are a couple variations to the concept of integration. The core building blocks for this software stack are generally split into the following components: Hardware, Drivers/Operating System, Middleware, Conditional Access Client, EPG Application, Virtual Machine Engine and Interactive Applications. In terms of variations of SI, it essentially falls into two categories, not so different to "White Box" & "Black Box" concepts used in testing - however, it does have a direct impact on the level of influence & amount of topic-specific knowledge the SI team has or is empowered with, thus having a direct impact on the outcome of the project.

Ultimately, the PayTV Operator owns the full stack that makes up the product. The components are often provided by multiple software vendors. Assembling these components into a workable stack is left up to the task of a Systems Integrator (SI). SI acts as the mediator, the aggregator, the arbitrator - assembler of  components, puts the build together, runs smoke & sanity tests, including full functional testing, investigates defects and assigns such to offending components. SI controls the flow of releases, plans the release schedules and is ultimately accountable for generating the launch software, thus getting it to deployment / operational space.

In a previous post on SI is King, I stressed the importance of SI. I still maintain that the role of SI is in fact the most important role in a STB project, SI has high visibility and high impact, the gateway to success and the gatekeeper for maintaining the integrity of the software. Without a strong SI team, your project is really dead-in-the-water, project will thrash for months on end and will likely result in a project doomed for failure.

In terms of growth potential for engineers, I personally believe, through my own hard-won experience as an engineer myself, having been involved in various engineering roles; as well as from my experience in managing projects across several development & integration teams, that Systems Integration (SI) is the ultimate place to be in, in terms of career progression and should be a natural development path for engineers seeking the next level from software development...

The effectiveness of the SI team is governed by the teams ability to execute on expert technical knowledge thus implementing best practices, streamlining processes, operating as an efficient well-oiled machine. More importantly, the strength of SI is determined by the calibre of its contingent Engineers, the strength of its workforce.

In this post, I will share my thoughts around the following areas:
It doesn't really matter on the context of Black Box or White Box, however, I do feel that Black Box SI is often counter-productive and is really at odds with the intent of true SI, but in some projects or commercial agreements, this is sometimes unavoidable. SI engineers who shine in Black Box SI would probably excel even more if they had access to source code, build tools, etc. In the whole however, when it comes to requirements for SI engineers, they should be equipped to work equally well in any context.

Tuesday, 2 July 2013

Programme / Systems Readiness Heat Maps


In the past I've written about the make up of the Digital TV (DTV) ecosystem or "value chain" making it quite clear that the system in itself is a complicated mix of different systems, often provided by more than one vendor. To recap, you can follow-up on these posts:
It is not very common for DTV projects to impact the end-to-end value chain, where implementing a new feature or major product launch touches upon just about every element of the system, but it does happen. It is complicated, but it can be managed. It takes an investment in effort, diligence, rigour, sense-of-strong-will, and patience to work with the different teams, to coherently come together in delivering the overall plan.

In this post, I share what I've come to find quite a useful tool: the Programme/Systems Readiness Heat Map.

It is well-known that human beings think best in pictures. As the well known works of Edward Tufte teach us, that visualisations are a powerful way of communication. A visualisation, if done correctly or smartly, can accurately reflect or communicate the state of "things" or "tells a story" so that almost anyone can just, from looking at the picture, get the message.

So, as a Programme or Systems Projects Manager, dealing with complicated technology components, and time lines are highly parallelled and intertwined, when it comes close to the final delivery stages of the project, what is the best way for you to communicate the overall status of readiness of the system?

Sure, one can use a series of PowerPoint slides, representing the status of each Work Package, focusing on the key delivery criteria for each component - this is usually what most PMs do anyway in reporting overall Project Progress via status reports. Your SteerCo have very little patience to wade through 30 slides of PowerPoint tables...

So, what the Heat Map does is simple: On a single piece of paper (okay, maybe the size is A3!), the heat map shows the state of the entire System / Program, focusing on the key criteria for each component that determines the fit-for-purpose state that your SteerCo & Executive can use as input into making the decisions for approving final deployment: Go Live. Essentially the Heat Map is represented as an n x m matrix, with n number of components to track, m the number of metrics/criteria that must be met to guarantee successful implementation to deploy. Each entry is given a value or an associated Heat Colour (Red, Amber, Green), that when all entries are filled in, the reader can quickly ascertain the state of readiness (are we hot or cool or in between?)

I will talk you through a generic template that I've used in my own programs...

Wednesday, 12 June 2013

PayTV Interactive Applications is dying slowly, but surely

Interactive PayTV is dying slowly, or was it dead on arrival? Imagine these scenarios:
  • OK TV, Have any of my favourite shows been recorded lately?
  • OK TV, Find me something nice to watch - I am feeling good
  • OK TV, I've had a crap day at work today, put something on that'll make me unwind and relax
  • OK TV, What are my friends watching now?
  • OK TV, What show is trending on the social scene?
  • OK TV, What's selling hot on Box Office today? Show me the trailer, skip the ads please.
  • OK TV, Let me see what's happening on my hangout?
  • OK TV, Give me the top five recommendations today
  • OK TV, What's the latest news headlines?
  • OK TV, What's happening with Syria today? Connect me to any Live News Stream?
  • OK TV, What's making waves on YouTube recently?
  • OK TV, Tell me the latest stats on the Formula 1 (Cricket, Football) scene
  • OK TV, What's the weather like at my mom's place?
  • OK TV, Any weather warnings I should worry about?
  • OK TV, Are there any live sports events happening in my area? Which is the closest?
  • OK TV, I'm in the mood for Star Trek - make it so!
  • etc
Get the picture? This is what interactivity supposed to be all about! TV is a passive medium, lean back, relax & watch TV. I don't want to read wades and wades of text on the screen! I've had a long day behind my PC, been coding all day or working with spreadsheets, the last thing I want is to navigate through some tiresome and clunky menu tree to find the information I want, then I must be forced to get up from my couch because the font & text is so small that I need to stand at least 3 feet away to read the screen! More work, more effort for me - I don't want to be interacting with the remote control to do stuff - I want to interact with my TV, not control my TV!

Yet, most of the PayTV operators have maintained to still support the original concept of Interactive TV - the famous Red Button, then the infamous loading time for the application, then interact with an eighties-style user interface. Whilst there are ways to workaround and improve the classic "Please wait...application is loading..." time, the original concepts have not changed that much.  There's a lot of chatter around Interactive TV 3.0 or second screen, etc - about the next wave of interactivity, that people would rather interact with a second-screen device (smartphone / tablet / etc), but this is not what my post is about.

Mostly, this post is part rant, and part explanation about the current predicament PayTV Operators find themselves. I've already a solution in my head that I think is the way forward, but it is probably disruptive to keep even the most open, objective PayTV operator running away at lightning speed! Just take a look at this absolutely cool demo shown recently at GoogleIO:


This is the future! I think Google is on the right track - Years ago, going back to 2005/2006, I was pushing my company to explore Voice & Text-To-Speech integration into Set-Top-Boxes. When we looked at Recommendations back in 2004/2005, we considered voice -- but hats off to Google, they've done it with Search, and I'm sure the next wave is enhancing their Interactive TV offering.

My elevator pitch: Times are changing! PayTV Operators must stick to their core business: Content provision, distribution, content protection & core information services. Partner with third parties to bring true interactivity to the user experience & platform. Focus more on Open Systems, don't control the whole world / ecosystem. Create strategic partnerships with Google (or other), creating a bridge between a closed PayTV world & the Open Social Apps world... 

This post is organised as follows:
  • Brief story about Interactive TV and Typical Architecture Model
  • Application Stores Overview - What PayTV Operators need to consider
  • My view of a possible Future Platform / Architecture