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?’ »

Prior to the industrial age, the world was essentially an agrarian and a trading economy. Production methods were often a craft and top secret, fiercely protected within a family and handed down from a master craftsman to his sons, and with no machinery for mass production, pretty much every product was handmade and unique, perhaps also customized, for its intended user. Industrial revolution made mass production and rapid movement of goods possible, and among other things, catapulted Britain into forefront of global economies. Gutenburg’s printing press was perhaps the first mass production system built by man. Subsequent inventions like harnessing of steam power made railways possible, spinning machines, and other advances in iron founding and chemicals pushed the envelope. However, a lot of these advances were limited to Europe and even more within the UK, which thrived on these advances and became the economic (and imperial) superpower well until the start of twentieth century.

However, by the start of twentieth century, America too woke up to industrial advancements and contributed to some of the most important advancements that still continue to touch our lives. The pioneering work by Eli Whitney on ‘interchangeable parts’ on his now classic cotton gin introduced the concept of modular design, followed up by Frederick Winslow Taylor’s groundbreaking work on scientific management led to the concepts of standard work and division of labor  (even if somewhat questionable and controversial in today’s context) and created the foundation for Henry Ford to envisage a mass production system with a moving assembly line where finished goods could be assembled from standard parts by semi-trained operators, e.g. Ford’s most famous Model T car in black color (“Any customer can have a car painted any colour that he wants so long as it is black”).

In essense, a production run, say in an automative parts production or even a car assembly line, is the repetition of a process that produces similar (or similar-looking) objects. Once the ‘process’ is ‘designed’, the job entails repeating the process till the desired number of objects have been produced. Clearly, the faster you produce those objects, the sooner you can put them up in the market for sale and start getting money. The more you produce, the more you are able to amortize the capex, and get lower per unit price over the long run. Intuitively, if you have to produce objects that are exactly alike in properties, shape, size, color or any other physical attributes achieved by the production process, you can ensure that your production machinery will need to be ‘programmed’ once and re-used several times later. So, if you run the paint shop (which seems to be the largest bottleneck in terms of time in a modern production setup) and need to produce purple colored chasis, once you set the process, stock the paint to desired levels, you are pretty much all set. Now imagine if you have to produce first 200 cars in purple, then next 30 in wine red, then next 70 in pearl white colors. Surely there needs to be some way (manual or otherwise) to alter the production process to suit such job order. Similarly, instead of producting 300 sedans, if you have to produce a mix of automobiles – say, 50 SUVs, 50 compacts, 150 sedans and 50 hybrids, your process will have to be different from the one that just produces 300 sedans in a single production run. While the customer desires options (don’t we all?), the manufacturer incurs additional time, money and resources in creating such options. From the manufacturer’s point of view, producing each piece exactly similar as the last one makes such great economic sense that he can create huge economies of scale made possible by principles of mass production. It simplifies the machine (and machine operations) required in plants, it standardizes the components required, there is no downtime to alter the production process, people don’t have to be retrained every now and then on different type of products, and all this make the entire production process very ‘controllable’ from throughput and quality perspective, and hence highly predictable. Elaborate statistical charts can be created based on prior experience on how much time it takes for a given production run, how much men (and women) and materials are needed to meet a given production target, and what levels of quality can be achieved based on statistical experiences. 

Continue reading ‘Why are we in this mess?’ »

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?’ »

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’ ?’ »

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 ?’ »

httpv://www.youtube.com/watch?v=gDDO3ob-4ZY

Continue reading ‘What is the Inventory of your Software Development project ?’ »

The Swiss Army manual says: When the map and the terrain disagree, trust the terrain. However, in software industry, there seems to be an unending effort to make sure the terrain is retrofitted so that it looks much more like the map in hand ! So, I have modified the Swiss Army saying to suit the reality in the software development community as: When the real-life and bookish process definition differs, it clearly shows you have not understood the bookish definition, and hence you must change the real-life until it looks like the bookish definition and then trust the bookish definition.

Statutory Health Warning: Reading this blog post further could be bad for health, especially for those who love the process vocabulary more than the process intent, see the means more clearly than the ends and anyday favor the established processes of the day even to solve newer class of problems that clearly require fresh thinking lest they end up shaking the establishment. Author takes no material responsibility for anyone proceeeding from this point beyond and suffering serious health problems because of the radical views presented in this blog.

The conventional definition, popular understanding and state of practice of Software Quality is seriously flawed. They have created a very lopsided perspective that adherence to certain standards is Software Quality, howsoever hard- or soft-baked those standards be. On one hand of the rather colorful spectrum are the die-hard process zealots who won’t stop short of anything less than an ISO, CMMi or the likes and on the other end of the spectrum are the neo-rebels who believe anything Waterfall is bad and unless anything is Agilized, it ain’t good enough. On the innumerable discussion boards that I subscribe and listen to, completely petrified to speak up lest be asked my credentials to back up my anti-establishment views, I find more productive hours being lost on what should be the exact definition of a ‘product owner’, what should an ‘iteration zero’ be better known as, and whether you pass the Nokia test or not. I find the neo-rebels falling in the same honeytrap that they once so detested and fought tooth and nail - compliance over creativity. I see more mail threads getting fatter and longer because there are linguistic differences that probably should be settled so that practitioner’s camp can have peace after all, but where is the Customer in all this ?

Continue reading ‘What is your Software Development Religion today ? And where does the Customer fit in that ?’ »