It’s surprising that the project management-related books in the bookstores disagree heavily with each other. Some focus on business strategy, others on engineering and scheduling processes (the traditional focus of project management), and a few on understanding of customers. But more distressing than their disagreements is that these books fail to acknowledge that other approaches even exist. This is odd because none of these perspectives—business, technology, customer—can ever exist without the others. More so, we are convinced that success in project management occurs at the intersections in these different points of view. Any manager who can see those intersections has a big advantage over those who can’t. Projects differ, but planning matters A small, one-man project for an intranet site doesn’t require the same planning process as a 100-person, $10 million project for a large ERP deployment. Generally, the more people and complexity you’re dealing with, the more planning structure you need. However, even simple, one-man projects benefit from plans. They provide an opportunity to review decisions, expose assumptions, and clarify agreements between people and organizations. Plans act as a forceful function against all kinds of stupidity because they demand that important issues be resolved while there is time to consider other options. As Abraham Lincoln said, “If I had six hours to cut down a tree, I’d spend four hours sharpening the axe,” which we think to mean that smart preparation minimizes hard work If you don’t know what you need to do, it’s too early to figure out how to do Project planning involves answering two questions. Answering the first question, “What do we need to do?” is generally called requirements gathering. Answering the second question, “How will we do it?” is called designing or specifying. A requirement is a carefully written description of criteria that the work is expected to satisfy. (For example, a requirement for cooking a meal might be to make inexpensive food that is tasty and nutritious.) Good requirements are easy to understand and hard to misinterpret. There may be different ways to design something to fulfill a requirement, but it should be easy to recognize whether the requirement has been met when looking at a finished piece of work. And a specification is simply a plan for building something that will satisfy the requirements. Warning: This is simple but handy view. In reality, these two activities -requirements gathering and designing/ specifying - are deep subjects, and worthy of entire books on their own!. Asking the right questions is crucial At any time in a project, there are basic questions that everyone should know the answers to. You might not always like the answers, but you and your team should know what they are. Most planning frustrations occur when there’s disagreement or ignorance about these issues. The questions (often called project-planning questions) depend on the type of project you’re working on. If it’s a new project (not a v2), then you’ll need basic questions to define the fundamentals. If it’s a small upgrade to an existing system, there may be fewer issues to consider. But no matter what the project is, do the exercise of running through the questions. It will force out assumptions and ideas that haven’t been recognized. The business questions The business view focuses on things that impact the profit and loss (P&L) accounting of an organization. This includes sales, profit, expenses, competition, and costs. Everyone should understand their P&L: it’s what pays their salaries or their contracts. A good business perspective means that the team has answers for the following questions: • What will it cost (people / resources)? Over what time period? Those responsible for the business perspective take bold views of the importance of these questions. They believe that the answers represent the bottom line for the organization and should strongly influence project decisions. However, the business view doesn’t mean that all projects must be slaves to revenue. Instead, it evaluates projects based on their contributions to the business strategy. For example, a strategic project might be essential to the organization but never generate any revenue. The technology questions The technology view answers how things should be done. It’s a materials and construction mindset. Some important questions are: • What does it (the project) need to do? The interdisciplinary approach These two points of view always overlap each other. Every business consideration has technical implications (or vice versa). Some decisions will need to be made that favor one perspective over another, but that shouldn’t be done by accident. It should support an intelligent strategy derived from getting as much value from each perspective as possible. One way to accomplish this is to establish early on that there will always be great technological ideas that do not benefit the business, as well as great ideas that are not possible with current technology. This gives everyone the power to identify one-dimensional ideas and call each other on them. But if no effort is made to bring divergent points of view together, project-planning meetings become battlefields for attacking and defending opinions based on these perspective lines (and not on the true merits of the ideas themselves). Often when we’ve consulted with project teams, the problem we were asked to help with had nothing to do with their ability to plan a project. Instead, there was an unresolved, or even unspoken, conflict of opinion about why one department is more important than the other. Their singular perspectives not only caused the problem but also made it impossible to see the cause of the problem. Free Consultation While MES maybe new to some people and customers may have questions, we will provide satisfying, understandable answers. Simply contact Factorytalk and “Call for a Coffee” for a free consultation. We are located at : Factorytalk Pte Ltd E-mail Address : |
