Language
 
Editorials - Call in for a Coffee
cc
"Project Management Theory in Practice"
October, 2005 : Edition No.8

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?
• What potential for revenue (or reduced operating costs) does it have? Over what time period?
• What won’t we do so that we can do this?
• Will it contribute to our long-term business strategy or protect other revenue-generating assets? (Even nonprofit organizations have a business strategy: there are always bills to pay, revenue to obtain, or revenue-generating groups to support.)
• How will this help us match, outflank, or beat competitors?

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?
• How will it work?
• How much time will it take to do, at what level of quality?
• How will we do it? How will we verify that it works as it’s supposed to?
• What technologies are readily available to us?
• What processes and approaches are appropriate for this team and this project?
• What won’t they be working on to work on this project?
• What applicable knowledge and expertise do our people have?
• How will we fill gaps in expertise? (Train/hire/learn/ignore and hope the gaps magically go away.)

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 Co., Ltd.

12th Floor, Liberty Square
287 Silom Road
Bangrak, Bangkok
10500 Thailand

Telephone : +66 (2) 630-4525      
Facsimile : +66 (2) 630-4527

Factorytalk Pte Ltd
25 International Business Park,
#04-106-107A,
German Centre,
Singapore 609916
Telephone :  +65 6562 7634       
Facsimile : +65 6562 7635

Website :

E-mail Address :

 
 


Our printable newsletter is available in .pdf format here.

Use Adobe Acrobat Reader to view and print this file.  If you do not have Adobe Acrobat, you can download it for free here. 


 
----------------------------------------------