Project Management in 3 Minutes
When the Pyramid of Giza was being built around 2500 BC, Project Management was not much of a fad. Maybe whip yielding Scrum Masters did have daily stand up meetings and maybe some engineers had the blueprint drawn up in some papyrus scroll, but that was all to it. No jargon, no certifications, no proud Project Managers with PMP badges. Yet we know the pyramid was one of the daunting projects of human history, one that modern engineers still marvel at. Was this project managed right? You bet! But modern organizations cannot operate like the Pharaohs. We can not whip engineers to build a project out – well not at least literally. As we have refined process over the years, including sophisticated terminologies like Work Breakdown Structure and Process Flow Diagrams and Trade-Offs, we have no doubt blown up something simple and rational into something more of a puff-and-show. But at the heart of it, Project Management remains simple and straightforward. Any project, of any proportion or complexity, can be defined, scoped and planned (at least the basic draft, not as a versioned scope document that clients will accept, duh!) by just answering in a few sentences the following 6 questions. WHAT Well let’s just answer that, shall we! What is the project all about? What needs to be done? Such a basic, such a primary question – yet I find Project Managers, Project Leads, Team Members and sometimes even clients struggling to answer that question – WHAT is the project all about? Even when someone starts a narrative, they usually go on to describe the WHAT in terms of multitude of scattered user stories and exception scenarios. Well, take a breath and get a hold! The WHAT of a project needs to be like an Elevator Speech – short, crisp and to the point. No matter the complexity or budget of the project, if you cannot define the WHAT of it in a few sentences, you really need to get back to the drawing board. WHY Even though we sometimes survive the WHAT session, what really get’s at us is the WHY. When I ask teams working on a project – WHY are you doing this project? I am always amused by the look of befuddlement in their faces. People go like – What do you mean WHY? As if I have just asked one of the most absurd questions that they have ever heard. When I nudge them further, they conjure up reasons like – Well because the company won this project or Because it will earn us money. There are some bad-ass who retort to my WHY with a smirk and a – WHY NOT? The WHY of a project is the soul of the entire project and is the crux of the solution that we as a service providing company or team is supposed to provide. The WHY is the answer to the problem the client wants to be solved. If the WHY is not clear to the team, it is usually like a driver steering a bus without knowing where they are headed. On the contrary, answering the WHY, again, in a few simple sentences, get’s the entire team on the same page in terms of the requirement of the project and also shift’s their focus from Execution to Solution. HOW Now that we have discussed and written down in a simple document and in very simple format, WHAT the project is about and WHY the client needs the project, we next come to HOW of the project. Answering this clearly and briefly will make sure there is distributed clarity in terms of the solution implementation. Do not mistake this simple description as a replacement to the FRD, but rather treat it as a premise to the same. Different team members of an ongoing project are often clueless about the basic yet critical information regarding what technology the project will be built on, what will be the associated technologies and what will be the solution model. Defining such simple details in this section as to whether the project will be developed as a single application or a CMS or a SaaS model application; whether the scripting language will be PHP or C# or DotNet and whether, if any, a framework will be used, goes a long way in achieving critical project clarity for the development team. WHO With most of the project understanding in place, it just remains to set up the team right. Though we ideally want the best team to work on every project, but unfortunately, we do not live in an ideal world! So we know the resource pool at our disposal. In this section, we can be realistic and quickly define the team who will work on the project. This will include defining the entire team – from the Team Leads to the Developers to the Designers to the Client Relationship Managers, if any. It is extremely crucial at this stage to list out the backup resources as well. Though such resources may not be available presently, but we must always have a list of back up resources named to jump into should the occasion arise (trust me, it always does!) WHEN A human may not live by a timeline, but a project must! Discuss and quickly frame up a timeline for the project. When will the requirements be discussed? How much time should be invested for requirement discussion? X number of days? Great! What if it extends to X+2 days? Ah, then the deadline just shifts further by 2 days, right? Wrong! Time has an Avalanche Effect. When a rock starts rolling at the mouth of an avalanche, it is not 1 rock that ends up at the bottom of the mountain, but a huge pile of rumbling, disastrous heap! It is the same with time delays. A 2 day delay in the requirement analysis phase may end up delaying the project by months. So in this section of the document, quickly draft an initial and ideal project timeline, but also draft 2-3 other parallel timelines for delay scenarios. That way, if we jump and miss the rope, we will
