manage well

In the age of nano attention-spans of people, the tendency and respect for planning things upfront has taken a serious beating. The mainstream logic is to simply ‘play by the ear’ because there are far too many moving parts to be completely accounted for and properly factored-in – and in any case, by the time the plan goes to execution, ground realities would have changed beyond recognition, thereby rendering the plan completely useless  by that time.  In software development, an inaccurate predictive long-range model such as Waterfall has been replaced by more accurate adaptive short-range Agile methods that solve the line-of-sight problem but don’t address the original problem – that of planning a large project with its own share of uncertainties.

While none of those arguments might be wrong par se, we conveniently ignore the fact that that is the nature of the beast – and we need to understand that planning is not a single-pass 100% process that stays current forever. Further, just because things will eventually change is not a good enough reason to abandon any systematic efforts to understand it, if not to tame it altogether!

While preparing my lecture notes for a recent class on planning, I decided to explore the subject of planning through the ages – using various quotations over a period of time. I sorted them in chronological order in order to understand how human mind has evolved the thought process behind planning. What came out from this exercise surprised me – it seems like the values associated with planning are as timeless as the fundamental human nature. The age-old wisdom was that a ‘stitch in time saved nine’ and hence there was a focus that ‘prevention is better than cure’. Some might argue their world was not so complex and dynamic. I disagree.

Continue reading ‘Is Planning an old idea whose time is up?’ »

How do you decide what tasks to schedule first: the complex ones or the easy ones? the short ones or the long ones? the risky ones or the sure-shot ones? Most often, this task sequence is determined by hard logic, soft logic, or some other external constraints. However, how do you decide when there are no such contraints?

If we look at the risk driving the project lifecycle and scheduling, then it is natural to expect high-risk tasks being tackled at the start just so that we are systematically driving down risks in the project and achieve higher certainty levels as we get close to the project. However, it seems inconceivable that someone will cherry-pick the easy tasks first and leave all high-risk ones for the end! Clearly, that is setting up the project for a grand finale of all sorts!

Could complexity be a good measure then? What will happen if we take high complex tasks first? Surely, that will lead to tackling some of the most difficult problems first, and there might also be a high level of correlation between complexity and risk. So, taking this approach is also likely to significantly lower a project risks. However, not all tasks are created equal. It is likely that high-risk tasks not the longest, so while the project makes appreciable gains in lowering the risk, but doesn’t make a whole lot of progress.

Continue reading ‘How do you schedule tasks in a project?’ »

For decades now, the project management world is divided between top-down estimation and bottom-up estimation. While a top-down approach might have limitations, it perhaps is the only way to get some meaningful estimates at the start of a project. A bottom-up approach might be a great way to get more accurate and reliable estimates but you might have to wait for a problem to be whittled down to that small a level to get such reliable estimates. Both are required for a comprehensive and useful project planning, but unfortunately, most people see one over other, and the Agilists abandoning top-down in favor of the highly accurate but low-lookahead bottom-up methods.

A top-down estimation is a great way to abstract the problem without worrying about its nitty-gritties, and come up with a workable estimates when there is no other source of getting any better estimates. At the start of a project, when making a realistic WBS is a remote possibility, the only way one could get some estimates is by top-down estimation techniques such as

• Expert Judgment
• Wideband Delphi Method
• Analogous Estimation
• Parametric Estimation

Continue reading ‘Your estimates or mine ?’ »

The concept of planning has a very intuitive appeal, irrespective of the type and size of endeavor. Who wouldn’t want to undertake an activity without a little bit of upfront planning? Will you take your car and just head out for the next family weekend in the neighboring town – without first checking if your car is roadworthy for the long drive, has enough gas, or needs a visit to the garage before the long drive? Will you buy a house without first checking your cash flows and other commitments for the next couple of years? Will you get your kids admitted to the nearest school you come across, or you will do little bit of investigation and plan is based on your specific needs and child’s comfort?

Still then, it comes as a great surprise when many among us disregard the benefits of planning things upfront. While they might still succeed in a trivial pursuit, for it might present very predictable outcome, require relatively risk-free approach, is generally easy to recover from a bad position, have virtually all resources at one’s disposal, etc. While such trivial ‘projects’ might not demand a rigorous planning, we should also note that often such planning is a very intuitive process, one that happens very effortlessly and unconsciously in our minds. Such planning, or several of its elements, have been executed so many times that one doesn’t have to think of anything else – it just happens. To an untrained eye, it might appear like a careless approach where nothing is being planned, and yet the actors seem to be in supreme control – it is nothing short of magic! However, let the vision not get the better of logic.

However, for any non-trivial problem, or a trivial problem with a few key changes, or some last-minute unpleasant surprises, the life is not that easy. They transform into wild beasts that don’t obey their masters anymore, they behave randomly (or at least unpredictably), and unless you address them proactively, they are only more likely to make things increasingly difficult for you. What follows then is the endless loop of firefighting (often leading to ‘immortal projects’ that I conceptualised in my earlier blog post “From Project Immortality to Project Moksha“). So, why is it that some people refuse to plan their projects, choosing instead to clean up their mess over long evenings and frustrating weekends over the next several months? Here are some of the reasons that I have come across:  

Continue reading ‘32 Reasons Why People Don’t Plan Projects’ »

What is worse then an anarchy ? You might say that is the absolute abyss, but I think blind allegiance is even more dangerous (and that includes following the letter but tweaking the spirit – things like ‘creative accounting‘ or its parallels in every field). Anarchy at least allows for things to become ‘better’ in order to survive – whether it is the idealogy, resistance, or even musclepower, or any other ills (and hopefully at some point, social forces of constructive destruction take over). But in a land where unquestionable compliance and blind allegiance rule the roost, IMNSHO, is like a terminal patient off the ventilator support. When people are on their deathbed, they don’t regret things that they did but much rather the things they did not do!

In project management, life is no less colorful. We have process pundits (read “prescription police”) shouting from the rooftop with a megaphone on how heavens will strike them bone dead with lighting if they ever as much as strayed from the ‘standards’. When projects are being postmortemed, we don’t often ask what or why the project did something that they did, but why they did not do things that they did not do. And quite often, you find answer in the map itself – because the map did not factor-in those conditions that were actually encountered on the terrain, the blind followers just followed the Pied Piper and danced their way into the river of death. What a terrible waste of human talent.

Why do we get stuck with methods so much that our result-orientation takes a back seat ? I think there might be many answers, but some that deserve merit:

Continue reading ‘Our methodology is 100% pure, our result is another thing!’ »

It’s not about the project management methodology anymore. Frankly, it never was, even though it has triggered off some of the most senseless wars in the history of project management. Starting with Frederick Winslow Taylor‘s Scientific Management to Henry Ford‘s assembly-line based mass production system and eventually landing in a ‘flavor-of-the-day’ methodology (CMM, ISO, Agile, XP, Scrum, Lean, Kanban….and add your favorite one here), project management community, especially in software field, has seen it all…and still counting! All these project management methodologies have been eulogized as silver bullets in their heydays (and some still continue to be worshipped as we speak), and have subsequently been improved upon by the next wave of innovation driven by ever-evolving business needs, state of technology and the sociological changes at the workplace. However, each predecessor has been uncharitably rejected and unceremoniously relegated to trash by every successive methodology champs. However, that doesn’t seem to have stopped project woes, certainly not – going by the claims made in their marketing brochures . So, whom are we to trust – the overzealous champs or their ever-evolving methodologies ?

For most practitioners, novices and experienced folks alike, project management methodology became this one large target to shoot at, the advertisement to get the project deal, the crutches to hold the project on to, the lame excuse against change in project specs, the insurance against failures, perhaps the…raison d’être for project managers ? “Sorry, the manual says do it this way, we can’t change that”. “The process handbook says we can’t take any changes anymore – tell customers to wait until the next release which is just six months away”. “You are not approved to prototype, so stop that effort”. “Our company’s org structure doesn’t allow an engineer to manage the project – the risks are too high”. “Our metrics are within the control limits, so I don’t understand why engineers fear a project delay”. Goes without saying, they come in all hues. 

Little did we realize that the ‘problem’ was a moving target. We continued to ‘evolve’ our ‘solution’ blissfully unaware that the problem was also upgrading itself. Every new fix has led to a newer generation of problem that seems to have outpaced the development of solutions – so far, and I see no good reason why we will never have a ‘perfect solution’ for every type of problem. So, it doesn’t amuse me when people on Agile / Scrum discussion boards try to indiscriminately apply those principles to just about every type of problem under the sun, and then when, predictably, things don’t work, they blame that Agile / Scrum is not being applied in its spirit. Have you ever seen a project manager so baptized that he won’t think beyond the book ? I think those blind preachers are just living like a frog in a well.

Continue reading ‘Does your project management methodology lets you free think?’ »

Did you check out the Agile Skills Projects yet ? It seems to be a new and interesting initiative to “… establish a common baseline of the skills an Agile developer needs to have, including a shared vocabulary and understanding of fundamental practices”.

They talk about Agile Skills Matrix that has seven essential skills, or the Seven Pillars, organized into five skill levels.

Seven Pillars include:

Continue reading ‘Codifying Agile Skills or creating more checklists ?’ »

This is an interesting update on software trends:

A recent survey of more than 6,000 senior-level business leaders and software development executives found optimism for higher IT budgets and a preference for outsourcing, agile methods, and enterprise applications. In the survey, sponsored by software consulting firm SoftServe, 60 percent of respondents reported increases in 2009 IT development budgets, despite the uncertain global economic climate. Some 26 percent indicated that budgets had increased by more than 10 percent over 2008. Some 38 percent said they use some type of software development outsourcing. Of those, 67 percent used locations in India, followed by the emergence of Ukraine, China, and other Eastern European countries.

Continue reading ‘Software trends survey…’ »

 Large teams might be inevitable in certain large endeavors, but there are several benefits of small teams. A small team can build and maintain a strong culture and a character that gets better with time. Small teams quickly learn the invaluable skills in teamwork and interdependence that lead to higher efficiencies while ensuring that individual team members don’t end up competing against each other but rather collaborate on the common objectives. Small teams also mean small egos

One of the biggest motivations of making smaller teams is to provide higher levels of transparency and task accountability to individual team members. A large team tends to hide inefficiencies, both of its structure and of its people. One particular problem in a large team is the problem of “social loafing” – something that is perhaps best described in this poem by Charles Osgood:

Continue reading ‘Addressing the issue of “social loafing” in large teams’ »

At its core, productivity for a software team (often wrongly termed as programming productivity because software development is much more than mere programming) looks like a great idea. In its simplest form, it compares output of the team (amount of useful and usable software created, amount of unnecessary rework done, number of defects produced, etc.) to the input (time, effort and resources invested in producing software) factored-in by the uniqueness of the given software  endeavor and other external environmental factors (complexity of the software being produced, impact due to team sizes, nature of team spread and its familiarity with the problem at hand, problem domain, and so on). Unless you are willing to discount software development as a non-business critical activity undertaken purely for the labor of love that should not be ‘measured’ lest it dilutes the very ethos of software development as a creative cognitive endeavor, one might agree, albeit reluctantly, that some measure of how well we are doing is clearly in order. Can you think of a single business activity where such a measure should not be done?

In last few decades, researchers and statisticians have tried to create quantitative measures of productivity. However, due to an often unilaterally percieved inherent ‘uniqueness’ of every software endeavor, practitioners have consistently rejected such measures contending that there are either far too many assumptions in its definition and far too many variations in practice, or both. Instead of focusing on the ‘vital few’ commonalities, it is only unfortunate that practitioners have virtually rejected productivity measures in all forms by considering the ‘trivial many’ differences. What could have gained the industry by considering a big-grain definition of productivity was unfortunately lost because of focusing on decimal-digit precision of productivity measures.

In this blog, I will discuss the subject of productivity from a conceptual plane, and explore how Lean thinking helps us understand it little better by establishing a correlation between wastes in software development and productivity of the team. Lean thinking is much more than identification and elimination of the seven types of wastes, but I will only take up the issue of wastes in this blog.

Continue reading ‘How Lean thinking improves productivity in software teams?’ »

Agile thought movement has been around in different stages of evolution (and not to mention, different vocabulary from different preachers and schools of thought) from 1960s – perhaps it always co-existed with its better-known but half-effective cousin, Waterfall, all those decades without ever becoming a mainstream / preferred method of solving complex problems. Declaration of Agile Manifesto in 2001 was a watershed event, and the body of literature that has grown since then is simply mindboggling. There is a huge experience base on various Agile methodologies and methods that seems to be gaining firm ground globally every single passing day.

Divide and Rule

There can’t be any doubt that the fundamental idea to approach a problem in smaller pieces is great – it is logical, it is result-oriented, it is economical and it is highly intuitive. After all, the Imperial British conquered half the world by their brilliantly cunning doctine of ‘divide and rule’. It allows the human mind to focus on what is ‘visible’ here and now as opposed to worrying endlessly about the entire length and breadth of the problem which may never ever be crisply definable, or might require a disporportionately large amount of time (and effort) to clearly define it – by which time it is quite likely that the problem might have undergone changes due to natural ageing or changes in environment around it, or an improved clarity into the problem has given rise to another thought process about its solution, or both. Frankly, none of them is bad in the sense it is always better to know more clear definition of the problem or a more clear definition of the solution. The only problem is that it takes an inordinately large amount of time to reach there, with no mechanism to know if what is being considered will actually work as envisaged. While executing, one could encounter several more unknowns on the way that force changing the laid-out strategy. However, when you slice the problem in meaningful increments, you allow the solution to grow, one slice at a time. Of course, you still need to have the strategy to accomplish the top-level vision – but the working plans must not attempt to address that entire strategy in one single-pass. There must be a mechanism to (a) breakdown a problem into meaningful slices that (b) can be accomplished individually and incrementally to (c) make a definitive progress towards the eventual goals (d) without unduly front-loading the progress by later-day uncertainties. Agile encourages establishing a beachhead and then reinforcing it, slowly and steadily as opposed to landing in the middle of a battlefield and getting fired at from all directions. As a concept, this is splendid.

Continue reading ‘Why Agile doesn’t sell with Management ?’ »

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.

  Continue reading ‘Do you follow Project Management ‘religiously’ ?’ »

This is the text from a recent announcement for a course by Ken Schwaber on “Flaccid Scrum – A New Pandemic?” (text underlining is mine):

Scrum has been a very widely adopted Agile process, used for managing such complex work as systems development and development of product releases. When waterfall is no longer in place, however, a lot of long standing habits and dysfunctions have come to light. This is particularly true with Scrum, because transparency is emphasized in Scrum projects.

Some of the dysfunctions include poor quality product and completely inadequate development practices and infrastructure. These arose because the effects of them couldn’t be seen very clearly in a waterfall project. In a Scrum project, the impact of poor quality caused by inadequate practices and tooling are seen in every Sprint.

Continue reading ‘Blame your “flaccid developers” and your “flaccid customers” for your poor quality products !’ »

Building Pyramids is one of the most common examples and metaphors in project management, and should I also add, perhaps one that is almost always discussed about by people who have practically no knowledge of construction engineering, let alone experience in building a pyramid (after all, I don’t know too many people who can claim to have built a pyramid). There is always a classic problem of what is the right way to build a pyramid: if you go by the much-maligned and clearly fallen out of favor ’waterfall’ way, what happens if the King dies midway and the Pyramid is still unusable ? Worse, what if the King comes half-way down the project and sees bottom half of the pyramid and remains unimpressed with the sight and either wants to change the project specs, or worse, wants to stop the funding because he is not happy with what he is getting. OK, you want to build the top first. What if the King finds the explanation of building the Pyramid top-down funny (remember, there is no past precedence of your idea, and you might be ridiculed for your ideas – it is 2500 BC, after all) and all he sees on the ground is a miniature Pyramid ? What happens if a rival King starts constructing a bigger pyramid – can you now change the designs and make your pyramid bigger than the rival King’s ? Surely, there are obvious limiations of this model.

The other alternative is building it the ‘Agile’ way - starting with a miniature fully-functional pyramid and then incrementally building it inside-out. Theoretically, it sounds like the right thing to do – if and when King comes for inspection (and you can always count on that !), he always sees a ‘complete product’ albeit a miniature one. If he is impressed by the ‘plan’, he might release more funds and theoretically, the construction could go on perpetually, i.e., until when the King one days breathes his last. That day, right after the next ‘iteration’, his body could be laid in eternal peace in the majestic pyramid. However, there is a major problem with using Pyramid metaphor to justify Agile way of construction. Most of us who are simply ignorant about construction engineering treat the problem as building a Lego Pyramid – there is only the civil component of construction that is considered in any well-meaning debate. What about plumbing, what about electricity (ok, there was no electricity those days but you surely need air and light ducts to serve the purposes that electricity would have served otherwise), what about the state of technology that was available back then, what about stairways, what about interiors, and so on. Can all these be built inside-out ? Construction engineering might not entirely agree with building a Pyramid incrementally.

Well, there are critics on both sides of the thick and high wall that separates these two worlds (with some of them, perhaps, perched atop the wall as well) and there seem to be strong emotional views about which is better and why. In this post, I will not add anymore fuel to fire, but share an interesting thing that I came across. Chances are, irrespective of what camp you belong to, you will find this simluation exercise interesting, and guess what, you actually get to build a pyramid ! There is this great game on BBC site that tests how good a project manager you are – by playing a game to build The Great Pyramid ! Here is what the text reads:

Continue reading ‘So you think you are a top-notch Project Manager ?’ »

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.

Continue reading ‘PRINCE2 handles Project Tolerances better’ »