Category Archives: PRINCE2

How many balls does your project manager juggle?

A Software Project Manager’s job is often thankless. In a small team, this role is not differentiated enough, and is more ornamental than functional, the project manager being a regular individual contributor just like other team members, for most part of the project. In a large team, project manager often quickly loses respect from the foot soldiers as he is not seen ‘techie’ enough anymore. From a people management perspective, it is all about staying out of a popularity contest, if there ever was one. From project management point of view, there is an assymetric or non-linear reward-punishment scale: when a project succeed, more credits are given to the team, stakeholders and other environmental factors, while when the project fails, the responsibility squarely rests with the project manager. And as if that was not enough, new-age methodologies like Agile have altogether eliminated this role, I must add, rather prematurely. 

So, what is it that a software project manager really ‘manages’? What are the decision-points that have potential to shape the successful outcome of a project? Quite often, they are ‘invisible’ to naked and untrained eyes, and rest of the times, it is encapsulated in an organization’s standard process (whether written down, or unwritten). So, it doesn’t come as a surprise when the team is naive about the real value-addition by a project manager, or the upper management discounting its importance. However, as our dear friend Sherlock Holmes has taught us – absence of evidence doesn’t mean evidence of absence. So, let’s take a stock of characterstics of software projects – things that impact design and management of a software project, whether or not they all apply to every single project:

  • Scope: Fixed, changing, feature creep, “Featuritis”
  • Size: Size of software, development cost, number of people
  • Schedule: Length of schedule, fixed schedule, variable schedule
  • Complexity: Volume Complexity, Cyclomatic Complexity, Innovation, NPD (New Product Development) 
  • Project Management Methology: PMBoK, PRINCE2, CMMI, Agile,
  • Development Paradigm: Waterfall, V-model, W-model, Spiral, Scrum, XP, Kanban,…
  • Location of teams: Collocated, distributed, virtual
  • Quality requirements: 6δ, Mil-Standards, FDA, Carrier-class or Five Nines (99.999), Enterprise Class, Web, HA, Mission-critical
  • Technology: Existing, obsolete, brand new, evolving, pre-standards
  • Team Structure: Command & Control, Democratic, Self-organizing, Self-managing, etc.
  • People: Skills mix, Experience, Domain Knowledge
  • Tasks/activities: Unpartitionable vs. division of labor, expertise vs. fungibility, task dependencies, uncertainties, risks, estimates, 

This is not an exhaustive list of issues that impacts most of software projects, but gives a reasonably good flavor of what all does a typical project entails. If it helps, try to visualize an aircraft pilot in the cockpit with dozens of buttons, bulbs and controls around him – to fly an aircraft requires perfect coordination of all those buttons and levers – in the face of air pockets, turbulence, detours, landing delays and so on. Similarly, the project manager must apply right pressure and make right decisions on such factors and other decision-points to ensure that project makes a perfect three-point landing. 

We can also think of all these juggling balls – knives and burning balls, that a project manager juggles all the time – while maintaining balance walking on a high beam. Drop one ball, and the entire show comes down crumbling, but perfect show requires every single detail going absolutely right. To make the matters worse, these characterstics are dynamic – they change in size, impact and priority right through the entire project lifecycle. So, if an initially innocuous project factor is ignored in the early stages, it might well grow into a wild beast by the project is on the tarmac and ready for take-off. A pragmatic approach is to allocate proportionate amount of time and effort on each of those issues on a routine basis and re-arrange the pieces en route.

Do you recognize these decision-points in your software development project, irrespective of what methodology you use? Or, do you take most of these for granted, and look at them only when your project manager drops one of these balls?  

Do you follow Project Management ‘religiously’ ?

Project Management is perhaps one of the most fiercely debated and grossly misunderstood disciplines in the software field currently, hence let me throw in a disclaimer first: if you are a small team of experts and/or people well-known to each other (e.g., have worked together as a team earlier), and situated in a collocated fashion, doing a lot of ‘creative work’ that can’t be very ‘accurately’ scoped, let alone managed; you probably will find ideas of formal project management a huge overkill (on time, effort, money and might even seem to stifle creativity), and you might be better off considering ‘lightweight’ methods like Agile Project Management / Scrum in the context of software development (well, nothing stops you from deploying pieces of Agile / Scrum in a non-software context – it is based on common sense after all). Small projects, small teams can afford to define a process that exploits the tailwind:

  • A small and collocated team means more direct interaction among team members and lesser management overheads in formalizing project communication (e.g., project status reporting, team meetings, etc.). This reduces the time it takes to collate, transmit and share important project information and also decreases the possibility of information distortion or confusion. A small team means there is high signal to noise ratio in team communications, is also leads to a better utilization of time spent in transmissing, receiving or digesting communication. Further, to schedule any event, one can always convene impromptu meetings around a whiteboard or around the coffee table without worrying about people’s already double-booked calendars or finding a place large enough to fit the team for the next meeting, and so on.
  • Having a group of experts means there is low(er) need for managerial supervision and people are generally ‘hand-picked’ for their knowledge, skills and abilities that could typically be ‘mutually exclusive, collectively exhaustive’. This ensures tight interdepency and very high mutual respect among team members. There is lesser ‘competition’ among team members and everyone knows that “united we stand, divided we fall” which fosters teambuilding.
  • For a small project, a large swing in any of the project constraints (time, cost, scope) could seriously and irretrievably impact the project in a downward spiral. If the work is new to the team, it could spell bigger trouble, especially if there is no way to do mid-course corrections. Executing projects in an iterative fashion helps shorten the feedback loop and give a chance to make necessary corrections to improve its ability to stay on-course and eventually hit the target. Additionally, if there is a customer involvement on these short iterations, the quality and value of these feedbacks could improve substantially lest any decisions are made that are hard to change if required.

However, if your project is anything more than a handful of people, takes more than a few months and entails issues like external dependencies with multiple vendors and ISVs (Independent Software Vendors), substantial technical and managerial risks, subcontracting / co-development, etc., you probably might improve chances of success using a formal project management methodology like PMBoK or PRINCE2 than without it. Agilists will argue and disagree with me that Agile / Scrum is not suited for large projects, but if you are new to Agile as well as to large projects, you might want to consider all options and associated risks – don’t believe in what worked for others, it might or might not work for you (remember the golden rule – we are all different), and your company might have a different set of constraints and tolerance to performance. 

The size, complexity, criticality, and risk profile of a project, and organizational appetite for project risk and uncertainty, and organizational culture would generally determine the level and need of management control required, and hence one must always right-size the project management methodology based on the context. Both, PMBoK / PRINCE2 and Agile methods evolved in response to challenges seen in executing projects successfully. While PMBoK / PRINCE2 took the approach that projects most often failed due to lack right levels of management oversight, planning, execution and control; Agillists felt the key reason was the fundamental nature of software being a ‘wicked problem‘ that just could not be managed using an obsolete waterfall model of developing software – it needed a better way to develop software in short iterations with very close-knit self-managed teams.

Without getting my loyalties needlessly divided betwen the two of these approaches, I believe there are merits in both the thoughts. I refuse to believe that any non-trivial project can be managed by piecemeal iterations that give no commitment whatsoever on the overall project performance, nor give any method to assess if the overall project is indeed on the right track (so, even if first few iterations are achieving the desired ‘veolcity’, what is the guarantee that subsequent iterations will also move at the same pace?). On the other hand, doing an iterative development is highly intiutive and very effective way to learn from past experiences to plan next steps, especilly on any non-routine project that is full of unknowns and assumptions. To me, these represent ‘mix-and-match’ ideas that one should pick up and apply wherever required, without getting baptized to the school of thought. I find most process wars have taken the disproportionate dimensions of falling just short of religious wars – you have to belong to one of the camps, and must talk evil about the other camp to be seen as a law-abiding corporate citizen of that camp. In life, we borrow ideas around us – our housing society, professional volunteer society we volunteer for, our kids playground, gardening, home improvement, nature, science, religion, other cultures…without necessarily converting to another faith or religion or society just because we like an idea that we want to borrow. So why should that be required in project management methods ???

I think this process war will be won by pragmatics. Those who take a position on extreme ends of the continuum and insist on always applying a particular style as the panacea might be in for a complete surprise because no two problems were created equal. A prudent approach is to evaluate all options and then decide which is the best response to a problem, as opposed to blindly follow a project management approach ‘religiously’.

 

Do you follow your project management aproach ‘religiously’ ?

PRINCE2 handles Project Tolerances better

Most project management frameworks and methods advocate (and actually require) ‘point-estimates’ in planning and scheduling. By ‘point-estimates’, I mean there is a ‘hard number’ that seems to be etched in stone, leaving with no ‘tolerance’ or ‘leeway’ for the project manager and his team. Even though we all understand that estimates are never point-estimates (and hence the project commitments are never a point-commitment), we still expect a firm estimate (and consequently a firm commitment) from a project manager.

For example, a given feature must be required by 23-June, but there is no recognition of the fact that 23-June might still be a couple of months away, and several things could go wrong or could change meanwhile thus affecting the validity of this date. In real-life, there are always tolerances, some allowable, some acceptable, some tolerable and some simply unacceptable. This is not limited to schedule along, but also apply to cost, quality, scope, project benefits, etc. In some cases, the tolerances are defined, for example for the project scope, requirements might be prioritized as ‘M-S-C’ (or Most, Should and Could). In a previous organization I worked for, we had a great system for prioritizing all product requirements as ‘A’ (for current version), ‘B’ (implement if time is available) or ‘C’ (long-term requirement, but is being identified right now just so that designers and developers are available of how the system will evolve over time – so that, hopefully, they could build their designs futureproof). However, most product managers are unwilling to commit to such tolerances (or atleast unwilling to acknowledge existance of such scope tolarances), perhaps fearing that development team will straighaway prune down the list to bare minimum ones. Hence, in most organizations and projects, there seem to be two sets of commitments: one set is for the customer and one set is for the team. The one for team are the more stringent ones, but in the heart of the hearts, upper management knows that not all of them will be achievable and hence makes a little less stringent commitment (perhaps a more realistic one !) to the customer, thereby cushioning themselves against Murphy and the real-world. The project team slogs over months, often spending long nights and weekends alone in office just to try and meet the set of commitments that have been given to them, hardly ever realizing that there is another set of more realistic commitments that perhaps don’t acknowledge the cost of their commitment and efforts the team members are currently paying.

Agile methods, and Scrum in particular, take a major step forward and acknowledge that long-term plans are prone to later-day variations (and thus a waste of time and effort for all practical purposes) and hence favor short iterations to minimize the possibility of a project drifting or overcommiting itself to impossible deadlines due to such wild and optimistic estimates for long-range plans. But, it goes a little too far by simply accepting a world where no project tolerances are recognized, let alone identified for a project or its iterations. When a team member comes back and informs that he needs more time to complete a task than originally estimated, it simply makes suitable changes in the sprint burndown chart without placing an upper-boundary condition on how much off-estimation is permissible? As per the revised commitments, if the engineer is able to complete the task in the current sprint, well and good, but if for some reason, he is not able to complete, you simply push it out to the next sprint. It may not be necessarily bad, but definitely doesn’t place any upper-bound on the allowances available to a project team, and hence might not find good favor from upper management or product management in the long run.

PRINCE2 not only legitimizes the existance of tolerances at project level, it also allows a project to inherit a portion of those tolerances at stage plans and team plans at various stages thus giving a reasonable and mutually-agreed upon leeway to project manager and team managers to use those tolerances to manage the projects better (than, say, worrying about some 2-day delay that they can’t avoid or not able to meet a scope requirement because some peripheral feature can’t be met in given time). The mere act of legitimizing project tolerances creates a healthy understanding among all stakeholders that in real-world, there will be variations in future due to factors that might not be known or understood fully, or might simply change over time. A prudent project manager might not restrict himself to his current project management framework, and might want to look at what PRINCE2 has to offer in this regard.

How do you handle project tolerances ?