How project managers can deal with the vast sea of data and networks

By John Thompson

In this Internet age, have the abundance and access to data improved communication?

We have access to more data than any time in history and this grows with every passing day. Finding data is not what is difficult: cutting through the clutter and filter quality and value from the data ocean is becoming more challenging as this sea explodes. In parallel, personal connectivity is now instant and accessible to more humans on the planet than every before. This network is growing every day as more connections are added.

We are left with the problem of filtering Value from an exploding noisy and chaotic ocean of data. Where do we start?

The value of a network 

Metcalf’s Law defines the value of a network as the square of the number of nodes. [Network Value = nodes2]

Two telephones make one connection, five telephones make 10 connections and twelve telephones make 66 connections.

This value statement is only partially correct – if we define value as the usefulness of that Network. We can still be highly connected but share irrelevant or misleading information, debasing the real value of a connected world.

Connectivity is necessary, but far from sufficient to realize its full potential. If information is power, then how about Real-Time Information? Fresh information must then create even greater advantage in the market place.

So WHAT IS the direction of a valuable solution?

The Internet provides access to real-time data. In a connected world, every access point is at the center of that data universe.

The problem is, there is a sea of data generated every second on the Internet, but how much of it is valuable? How much of this data is useful for improving our lives? Can we turn data into useful information?
Stepping back a few years, global connectivity has grown exponentially from Morse code to copper wire and from hand crank telephones to dial-up phones and touch screen mobile phones that we all know today.

The question is: has conductivity improved the quality of information?

So what is quality information?

Or simply, what is information, period?

Information is simply the answer to the question asked!

If information is the answer to a question asked, then are we asking the right questions? Do we know what we are looking for when asking a question? Where do we even know where to begin, given this vast sea of data?

The world is now an always-on and real-time environment.

Project Management can now access and transfer critical information in real-time. How do we leverage this?

What are the critical questions during the three phases of PLANNING, SCHEDULING and finally EXECUTING a project? [or Portfolio of Projects].

Criteria to judge a great Project Management solution

What does a good solution look like in this new connected world?

In Planning

Network building should provide real-time collaborative no matter where you are located in the world, in the next office or on the other side of the planet.

Changes should be instant and visible to all team members in real-time.

‘What-If’ scenario building should be instant and ‘always-on’. Communication should be visual and verbal and accessible to all team members.
Scheduling a portfolio of projects

When releasing a project, what about the impact on all of the other projects that are already in process? Will resources be overloaded? Will we be taking on too much work? Will there be a period of peak resource loading, requiring planned outsourcing or overtime?

Is this project at high risk of not finishing on time? Answers to these questions must be instantly clearly visible. Dashboards must provide answers in real-time.

During Execution

Which projects are falling behind? If a project is falling behind, then which tasks are critical to bring the project back on track? Is the pace of execution sufficient to meet the due date without incurring additional costs?

If we take corrective intervention measures, is there any way of telling that these corrective actions will work? Again, answers to these questions must be instantly visible on real-time dashboards.

What do Project Managers really need?

If there were real-time answers to these questions, then there would be a great Project Management solution.

These answers would filter out irrelevant data and provide quality, relevant information. Project Managers would certainty be better positioned to contain cost and bring projects in on time.

Fortunately, there is a solution – Exepron Critical chain Project Management solution provides solid answers to all of the above questions. Exepron does this for a single project and more importantly a portfolio of projects having a shared resource base.

Every Team member has their questions answered in Real-Time and in full. Project Teams can now pro-actively respond to timely Quality Information

Just a few of Exepron’s informational Dashboards to keep your Projects on track; there are more tools and information to answer critical questions during Planning, Scheduling and Execution.

Every Step Counts in Successful Project Management

Introduction

The goal of any contractor is to build a project on time and within budget. To be an effective and productive contractor, one must have a complete understanding of the construction process, which includes not only building the project, but, more importantly, effective scheduling and management of the project. The contractor is ultimately responsible for managing its activities as well as the activities of the construction parties under its supervision.

Successfully managing a construction project is a four-step process. It requires that the parties establish a project plan, develop a project schedule, monitor the project schedule, and manage change events. Each step requires dedication and commitment from each team member, and each step in the process is essential to a successful project outcome.

Step 1: Establishing a Project Plan

The first step in successfully managing a construction project is establishing a game plan for executing the work. Planning should be thought of as completing a puzzle. All of the pieces must be identified, as they are all necessary to complete the puzzle. Furthermore, this process involves establishing the time and cost for each piece, ultimately leading to the total time and cost of the project.

The owner, architect or engineer, and contractor (if involved) will develop the plans and specifications for the project, as well as the overall sequence of construction activities. Each construction activity is then identified and assigned to a construction party, who identifies what is included in its scope of work and what related activities are not included. This identification process is critical for the contractor to know what activities have not been assigned and could “slip through the cracks.”

During the project planning phase, the project price is established using several methodologies, such as competitively bidding, utilizing a not-to-exceed value, or paying for the cost of the work plus a fixed fee. Once the project price is established, the contract documents are reviewed, approved, and executed. During project pricing, product suppliers and manufacturers are also assigned.

Also during this phase, the construction parties must educate themselves regarding the procedures, problems, and pitfalls of obtaining labor in the project location. They must assess availability of equipment, and of suppliers and manufacturers of construction components. Finally, all construction projects must meet the requirements of a regulatory governmental body, and the contractor is generally charged with obtaining all necessary permits.

Though every piece of the puzzle may not be known at the time of planning, an effort must be made to establish the full scope of work including the construction tasks. Once all of the “puzzle pieces” have been identified, assigned durations, sequenced, assigned to parties, and priced by parties, the project schedule can be developed.

Step 2: Developing a Project Schedule

Following planning,the second step in successfully managing a construction project is developing the schedule. Proper scheduling of the work tasks is the most critical aspect of the construction management process. The project schedule not only divides the work by activities, but it allows other parties to know what activities need to be performed and when. All construction parties need to be involved in planning the schedule and “buy into” the project sequence before construction begins.

A schedule can be as simple as a bar chart or as sophisticated as a computer model, but it must be developed and utilized. In a bar chart, each bar represents an activity and the length of the bar represents the activity duration. The bars can be stacked and placed so that as one activity is completed, the next activity in the sequence begins. The following is a sample bar chart schedule:

Typically, construction schedules are computerized. There are multiple software programs that produce reliable schedules, with most utilizing the critical path methodology (CPM) technique. Of all techniques available, CPM has proven to be the most useful and effective means of developing and displaying project progress.

Utilizing the CPM technique, each work activity is assigned a duration, start date, and end date, and is sequenced to follow and precede another activity. This sequence of events becomes a construction path. Generally, there are multiple paths created and many can occur simultaneously with and independently of one another. But there is only one continuous path that occurs from the beginning of the project to the end; that path is considered the “critical path.” Delays in non-critical work activity paths will generally not delay the overall project; however, delays to the critical path will. Planning and scheduling project activities with CPM software creates a logic diagram or network that can be displayed graphically.

In a successful construction project, the schedule becomes the project roadmap that all parties can review to determine when their respective work is sequenced. This allows parties to plan accordingly and ensure that they have the required materials, labor, and equipment available to perform their respective work. The schedule also informs construction parties what work precedes, follows, and occurs simultaneously with their work. This will allow each party to plan its work at the project site so that it will not interfere with other parties’ work. Further, the schedule allows the owner, architect, engineer, and contractor to plan decisions or approvals on certain project items or deliverables.

Step 3: Monitoring the Project Schedule

The third step in successfully managing a construction project is monitoring progress. Before construction begins, the schedule is a plan, also known (later on in the project) as the “baseline” schedule. However, once construction begins, the schedule becomes a dynamic tool that can, and often will, change depending on progress. The contractor is responsible for ensuring the schedule is actively updated, which includes recording activity dates and durations once they have occurred. This is known as an “updated” schedule.

Once the frequency of schedule updates is determined, the contractor will instruct the construction parties relative to updating their own work tasks. Normally, a schedule is updated monthly in order to keep pace with monthly payment applications. This should be a minimum frequency for all project schedule updates, no matter what the project.

Based on the new information, all schedule activities that should have started during the updated period are identified. All activities that were underway during the updated period are tracked and assigned progress. Finally, all activities that should have been completed during the updated period are identified. By performing these updates, any activity that is not on schedule will be recognized and can then be evaluated.

There could be a number of reasons why an activity is not on schedule, including a design change or work that was added or subtracted. Whatever the reason, the schedule must be updated and re-issued to the involved parties. Additionally, it is important to analyze all of the scheduled and executed activities to determine whether the updates will affect the project completion date. If a delayed activity was not on the critical path, it may not affect the timely completion of the project. However, if a delayed activity was on the critical path, the entire project will be delayed. If this occurs, the contractor’s obligation is to investigate the involved work activities and mitigate any delay.

Step 4: Managing Change Events

The fourth step in successfully managing a construction project is managing change events, as changes will inevitably occur. Managing the schedule to account for changes is different than monitoring progress and reflecting that progress in an updated schedule.

Whereas an “updated” schedule reflects progress of the ongoing work and the data date changes as appropriate, a “revised” schedule includes modifications to future baseline schedule work components or activities. These modifications could include work activities broken down into more refined tasks to more precisely describe the sequence of events. An example of such a refinement could be breaking the foundation work into several activities such as surveying for footing locations, drilling the footings, assembling reinforcement steel cages, casting concrete for the footings, and setting foundation anchor bolts. A change to a specific activity such as this describes future work in more detail and is considered a revision to the schedule.

Once the construction has begun, it may be necessary to re-sequence certain activities to more accurately reflect project construction. In doing this, the activities that were originally scheduled to commence before and after the re-sequenced activity must be re-sequenced and re-scheduled as well.

Other changes to planned activities could include modifying durations. After a project begins, it may be determined that a certain activity planned to take two weeks to complete should actually take three. For this change not to affect the final project completion date, the schedule has to be adjusted to absorb the additional week duration. Or, if no other activity timeline can be compressed, the change must remain and additional manpower or manhours must be scheduled to compensate.

Other changes that occur on a construction project involve uncommon and common events. Uncommon events can include unusual weather, labor disturbances, and/or outside events that neither the owner nor contractor can control. Of these uncommon events, unusual weather is the most often occurring with the greatest impact on the schedule. Contractors include expected weather delays into their initial scheduling, but unusual weather, such as a hurricane, can affect overall project progress. Common change events include design changes, owner-added change orders, incomplete designs that have since become complete, or different conditions that occur on a project that were not anticipated.

Any changes that affect the future project schedule must be documented. Furthermore, these changes must be evaluated to determine the most appropriate revision to the planned schedule. All parties involved in the project must “buy into” the change or, if not, the revised construction activity must be modified to accommodate the involved parties.

If a contractor or its subcontractors delay their own work based on their own actions or inactions, the schedule should reflect the extended duration, and the cause of that extension should be documented. The contractor must assess the cause of the delay and pursue a solution. If there is insufficient labor, materials, or equipment to properly execute the work, the contractor must determine if additional resources can be utilized. If a contractor’s subcontractor is delayed, the contractor must assist in resolving the reasons for the delay. Furthermore, if the subcontractor is under contract with the contractor, the contractor is ultimately responsible, and it is its duty to rectify the delay and provide the necessary resources to put the project back on track.

Any revisions or routine updates to the construction schedule must be republished, distributed, and communicated to all parties involved in the construction process. It should be noted that the planned completion date should not be affected by publishing a revised schedule. If the planned completion date has been changed, the contractor must evaluate the project sequencing and determine how to avoid a different completion date than originally planned, unless a schedule extension is granted.

Conclusion

In conclusion, scheduling and managing a construction project is composed of four steps, including planning, scheduling work activities, monitoring construction progress, and finally, managing changes to the project plan. Without a proper and complete construction schedule including adequate updates and revisions, construction parties cannot be informed of and ultimately held accountable for the timing and duration of their planned activities. Further, it will keep parties informed of the status of others’ activities that may precede or follow their work. Finally, it is the contractor’s duty and the owner’s right to be continuously informed of construction progress. Adhering to these best practices will ensure a successful relationship between the owner, contractor, and subcontractors and thus, a successful completed project.

Source: Philip D. Barnard

Mistake? Solution.

Even experienced project practitioners make mistakes. Find out how to bounce back from three mistakes that commonly occur in project management. 

The most seasoned project managers are still not immune to mistakes. Here are three common errors experienced project practitioners make and how to recover.

Mistake: Keeping strategy close to the vest. Proven leaders may have mastered aligning projects to business strategy, but that doesn’t mean all team members see the connection. In global project teams, team members may not even speak the same language. Larger and highly complex projects often have numerous stakeholders with differing departmental jargon and metrics, which can get team members headed in different directions, says Michelle Wu, PMP, business solutions IT leader, GE Global Growth & Operations — Middle East, North Africa and Turkey, a PMI Global Executive Council Member, Doha, Qatar.

Solution: To get everyone on the same page, marching toward the same goal, a project manager should create a training session for team members, contractors and vendors, says Ms. Wu.

Provide company materials at this meeting and turn to the organization’s annual report as the ultimate authority on the company’s strategy. “[The annual report] gives context to varying combinations of working groups,” says Atul Gaur, project manager, energy technology company Alfa Laval (India) Limited, Pune, India.

Then, conduct weekly or monthly strategy updates with team members to mitigate the risks of straying from the overall strategic goals.

Mistake: Blowing cost estimates. In a deadline-driven world, time is scarce, and you might be tempted to cut corners by relying on experience alone to estimate costs. But comparing projects with similar requirements is only a start to estimating costs, not an end, says Adrian Celentano, PMP, head of learning and development, management consulting, global advisory group, KPMG International, a PMI Global Executive Council Member, Toronto, Canada.

Solution: When the budget’s overrun and a project practitioner pinpoints the source of the mistake, Mr. Gaur recommends reversing course by soliciting cost quotes from potential vendors for project expenses moving forward. Creating a wider vendor pool gives you more negotiating power to find less expensive solutions to the biggest unexpected cost drivers. It also helps when asking for discounts such as commissioning assistance or complimentary trips for troubleshooting.

Mistake: Failing to escalate. A project practitioner with years of experience might want to solve all issues alone — even ones that require executive-level attention — in an attempt to prove he or she is ready for the next career level. And that can have the opposite effect when a big problem derails the project.

Solution: Increase the number of regular meetings with the project sponsor to address project accomplishments and challenges, says Ms. Wu. This helps you reassure the sponsor that a failure to escalate won’t keep him or her out of the loop again.

“Every single project practitioner makes mistakes, and it happens quite a bit more often than everyone thinks,” says Ms. Wu. “But by refocusing on communications, resource allocation and creative problem solving, practitioners possess the ability to swiftly recover.”

PLANNING A PROJECT

By: Gerard M Blair

The success of a project will depend critically upon the effort, care and skill you apply in its initial planning. This article looks at the creative aspects of this planning.

THE SPECIFICATION

Before describing the role and creation of a specification, we need to introduce and explain a fairly technical term: a numbty is a person whose brain is totally numb. In this context, numb means "deprived of feeling or the power of unassisted activity"; in general, a numbty needs the stimulation of an electric cattle prod to even get to the right office in the morning. Communication with numbties is severely hampered by the fact that although they think they know what they mean (which they do not), they seldom actually say it, and they never write it down. And the main employment of numbties world-wide is in creating project specifications. You must know this - and protect your team accordingly.
A specification is the definition of your project: a statement of the problem, not the solution. Normally, the specification contains errors, ambiguities, misunderstandings and enough rope to hang you and your entire team. Thus before you embark upon the the next six months of activity working on the wrong project, you must assume that a numbty was the chief author of the specification you received and you must read, worry, revise and ensure that everyone concerned with the project (from originator, through the workers, to the end-customer) is working with the same understanding. The outcome of this deliberation should be a written definition of what is required, by when; and this must be agreed by all involved. There are no short-cuts to this; if you fail to spend the time initially, it will cost you far more later on.
The agreement upon a written specification has several benefits:

• the clarity will reveal misunderstandings
• the completeness will remove contradictory assumptions
• the rigour of the analysis will expose technical and practical details which numbties normally gloss over through ignorance or fear
• the agreement forces all concerned to actually read and think about the details

The work on the specification can seen as the first stage of Quality Assurance since you are looking for and countering problems in the very foundation of the project - from this perspective the creation of the specification clearly merits a large investment of time.
From a purely defensive point of view, the agreed specification also affords you protection against the numbties who have second thoughts, or new ideas, half way through the project. Once the project is underway, changes cost time (and money). The existence of a demonstrably-agreed specification enables you to resist or to charge for (possibly in terms of extra time) such changes. Further, people tend to forget what they originally thought; you may need proof that you have been working as instructed.
The places to look for errors in a specification are:

• the global context: numbties often focus too narrowly on the work of one team and fail to consider how it fits into the larger picture. Some of the work given to you may actually be undone or duplicated by others. Some of the proposed work may be incompatible with that of others; it might be just plain barmy in the larger context.
• the interfaces: between your team and both its customers and suppliers, there are interfaces. At these points something gets transferred. Exactly what, how and when should be discussed and agreed from the very beginning. Never assume a common understanding, because you will be wrong. All it takes for your habitual understandings to evaporate is the arrival of one new member, in either of the teams. Define and agree your interfaces and maintain a friendly contact throughout the project.
• time-scales: numbties always underestimate the time involved for work. If there are no time-scales in the specification, you can assume that one will be imposed upon you (which will be impossible). You must add realistic dates. The detail should include a precise understanding of the extent of any intermediate stages of the task, particularly those which have to be delivered.
• external dependencies: your work may depend upon that of others. Make this very clear so that these people too will receive warning of your needs. Highlight the effect that problems with these would have upon your project so that everyone is quite clear about their importance. To be sure, contact these people yourself and ask if they are able to fulfil the assumptions in your specification.
• resources: the numbty tends to ignore resources. The specification should identify the materials, equipment and manpower which are needed for the project. The agreement should include a commitment by your managers to allocate or to fund them. You should check that the actual numbers are practical and/or correct. If they are omitted, add them - there is bound to be differences in their assumed values.

This seems to make the specification sound like a long document. It should not be. Each of the above could be a simple sub-heading followed by either bullet points or a table - you are not writing a brochure, you are stating the definition of the project in clear, concise and unambiguous glory.
Of course, the specification may change. If circumstances, or simply your knowledge, change then the specification will be out of date. You should not regard it as cast in stone but rather as a display board where everyone involved can see the current, common understanding of the project. If you change the content everyone must know, but do not hesitate to change it as necessary.

PROVIDING STRUCTURE

Having decide what the specification intends, your next problem is to decide what you and your team actually need to do, and how to do it. As a manager, you have to provide some form of framework both to plan and to communicate what needs doing. Without a structure, the work is a series of unrelated tasks which provides little sense of achievement and no feeling of advancement. If the team has no grasp of how individual tasks fit together towards an understood goal, then the work will seem pointless and they will feel only frustration.
To take the planning forward, therefore, you need to turn the specification into a complete set of tasks with a linking structure. Fortunately, these two requirements are met at the same time since the derivation of such a structure is the simplest method of arriving at a list of tasks.

Work Breakdown Structure

Once you have a clear understanding of the project, and have eliminated the vagaries of the numbties, you then describe it as a set of simpler separate activities. If any of these are still too complex for you to easily organise, you break them down also into another level of simpler descriptions, and so on until you can manage everything. Thus your one complex project is organised as a set of simple tasks which together achieve the desired result. The reasoning behind this is that the human brain (even yours) can only take in and process so much information at one time. To get a real grasp of the project, you have to think about it in pieces rather than trying to process the complexity of its entire details all at once. Thus each level of the project can be understood as the amalgamation of a few simply described smaller units.
In planning any project, you follow the same simple steps: if an item is too complicated to manage, it becomes a list of simpler items. People call this producing a work breakdown structure to make it sound more formal and impressive. Without following this formal approach you are unlikely to remember all the niggling little details; with this procedure, the details are simply displayed on the final lists.
One common fault is to produce too much detail at the initial planning stage. You should be stop when you have a sufficient description of the activity to provide a clear instruction for the person who will actually do the work, and to have a reasonable estimate for the total time/effort involved. You need the former to allocate (or delegate) the task; you need the latter to finish the planning.

Task Allocation

The next stage is a little complicated. You now have to allocate the tasks to different people in the team and, at the same time, order these tasks so that they are performed in a sensible sequence. Task allocation is not simply a case of handing out the various tasks on your final lists to the people you have available; it is far more subtle (and powerful) than that. As a manager you have to look far beyond the single project; indeed any individual project can be seen as merely a single step in your team's development. The allocation of tasks should thus be seen as a means of increasing the skills and experience of your team - when the project is done, the team should have gained.
In simple terms, consider what each member of your team is capable of and allocate sufficient complexity of tasks to match that (and to slightly stretch). The tasks you allocate are not the ones on your finals lists, they are adapted to better suit the needs of your team's development; tasks are moulded to fit people, which is far more effective than the other way around. For example, if Arthur is to learn something new, the task may be simplified with responsibility given to another to guide and check the work; if Brenda is to develop, sufficient tasks are combined so that her responsibility increases beyond what she has held before; if Colin lacks confidence, the tasks are broken into smaller units which can be completed (and commended) frequently.
Sometimes tasks can be grouped and allocated together. For instance, some tasks which are seemingly independent may benefit from being done together since they use common ideas, information, talents. One person doing them both removes the start-up time for one of them; two people (one on each) will be able to help each other.
The ordering of the tasks is really quite simple, although you may find that sketching a sequence diagram helps you to think it through (and to communicate the result). Pert charts are the accepted outcome, but sketches will suffice. Getting the details exactly right, however, can be a long and painful process, and often it can be futile. The degree to which you can predict the future is limited, so too should be the detail of your planning. You must have the broad outlines by which to monitor progress, and sufficient detail to assign each task when it needs to be started, but beyond that - stop and do something useful instead.

Guesstimation

At the initial planning stage the main objective is to get a realistic estimate of the time involved in the project. You must establish this not only to assist higher management with their planning, but also to protect your team from being expected to do the impossible. The most important technique for achieving this is known as: guesstimation. Guesstimating schedules is notoriously difficult but it is helped by two approaches:

• make your guesstimates of the simple tasks at the bottom of the work break down structure and look for the longest path through the sequence diagram
• use the experience from previous projects to improve your guesstimating skills

The corollary to this is that you should keep records in an easily accessible form of all projects as you do them. Part of your final project review should be to update your personal data base of how long various activities take. Managing this planning phase is vital to your success as a manager.
Some people find guesstimating a difficult concept in that if you have no experience of an activity, how can you make a worthwhile estimate? Let us consider such a problem: how long would it take you to walk all the way to the top of the Eiffel Tower or the Statue of Liberty? Presuming you have never actually tried this (most people take the elevator part of the way), you really have very little to go on. Indeed if you have actually seen one (and only one) of these buildings, think about the other. Your job depends upon this, so think carefully. One idea is to start with the number of steps - guess that if you can. Notice, you do not have to be right, merely reasonable. Next, consider the sort of pace you could maintain while climbing a flight of steps for a long time. Now imagine yourself at the base of a flight of steps you do know, and estimate a) how many steps there are, and b) how long it takes you to climb them (at that steady pace). To complete, apply a little mathematics.
Now examine how confident you are with this estimate. If you won a free flight to Paris or New York and tried it, you would probably (need your head examined) be mildly surprised if you climbed to the top in less than half the estimated time and if it took you more than double you would be mildly annoyed. If it took you less than a tenth the time, or ten times as long, you would extremely surprised/annoyed. In fact, you do not currently believe that that would happen (no really, do you?). The point is that from very little experience of the given problem, you can actually come up with a working estimate - and one which is far better than no estimate at all when it comes to deriving a schedule. Guesstimating does take a little practice, but it is a very useful skill to develop.
There are two practical problems in guesstimation. First, you are simply too optimistic. It is human nature at the beginning of a new project to ignore the difficulties and assume best case scenarii - in producing your estimates (and using those of others) you must inject a little realism. In practice, you should also build-in a little slack to allow yourself some tolerance against mistakes. This is known as defensive scheduling. Also, if you eventually deliver ahead of the agreed schedule, you will be loved.
Second, you will be under pressure from senior management to deliver quickly, especially if the project is being sold competitively. Resist the temptation to rely upon speed as the only selling point. You might, for instance, suggest the criteria of: fewer errors, history of adherence to initial schedules, previous customer satisfaction, "this is how long it takes, so how can you trust the other quotes".

ESTABLISHING CONTROLS

When the planning phase is over (and agreed), the "doing" phase begins. Once it is in motion, a project acquires a direction and momentum which is totally independent of anything you predicted. If you come to terms with that from the start, you can then enjoy the roller-coaster which follows. To gain some hope, however, you need to establish at the start (within the plan) the means to monitor and to influence the project's progress.
There are two key elements to the control of a project

• milestones (clear, unambiguous targets of what, by when)
• established means of communication

For you, the milestones are a mechanism to monitor progress; for your team, they are short-term goals which are far more tangible than the foggy, distant completion of the entire project. The milestones maintain the momentum and encourage effort; they allow the team to judge their own progress and to celebrate achievement throughout the project rather than just at its end.
The simplest way to construct milestones is to take the timing information from the work breakdown structure and sequence diagram. When you have guesstimated how long each sub-task will take and have strung them together, you can identify by when each of these tasks will actually be completed. This is simple and effective; however, it lacks creativity.
A second method is to construct more significant milestones. These can be found by identify stages in the development of a project which are recognisable as steps towards the final product. Sometimes these are simply the higher levels of your structure; for instance, the completion of a market-evaluation phase. Sometimes, they cut across many parallel activities; for instance, a prototype of the eventual product or a mock-up of the new brochure format.
If you are running parallel activities, this type of milestone is particularly useful since it provides a means of pulling together the people on disparate activities, and so:

• they all have a shared goal (the common milestone)
• their responsibility to (and dependence upon) each other is emphasised
• each can provide a new (but informed) viewpoint on the others' work
• the problems to do with combining the different activities are highlighted and discussed early in the implementation phase
• you have something tangible which senior management (and numbties) can recognise as progress
• you have something tangible which your team can celebrate and which constitutes a short-term goal in a possibly long-term project
• it provides an excellent opportunity for quality checking and for review

Of course, there are milestones and there are mill-stones. You will have to be sensitive to any belief that working for some specific milestone is hindering rather than helping the work forward. If this arises then either you have chosen the wrong milestone, or you have failed to communicate how it fits into the broader structure.
Communication is your everything. To monitor progress, to receive early warning of danger, to promote cooperation, to motivate through team involvement, all of these rely upon communication. Regular reports are invaluable - if you clearly define what information is needed and if teach your team how to provided it in a rapidly accessible form. Often these reports merely say "progressing according to schedule". These you send back, for while the message is desired the evidence is missing: you need to insist that your team monitor their own progress with concrete, tangible, measurements and if this is done, the figures should be included in the report. However, the real value of this practice comes when progress is not according to schedule - then your communication system is worth all the effort you invested in its planning.

THE ARTISTRY IN PLANNING

At the planning stage, you can deal with far more than the mere project at hand. You can also shape the overall pattern of your team's working using the division and type of activities you assign.

Who know best?

Ask your team. They too must be involved in the planning of projects, especially in the lower levels of the work breakdown structure. Not only will they provide information and ideas, but also they will feel ownership in the final plan. This does not mean that your projects should be planned by committee - rather that you, as manager, plan the project based upon all the available experience and creative ideas. As an initial approach, you could attempt the first level(s) of the work breakdown structure to help you communicate the project to the team and then ask for comments. Then, using these, the final levels could be refined by the people to whom the tasks will be allocated. However, since the specification is so vital, all the team should vet the penultimate draft.

Dangers in review

There are two pitfalls to avoid in project reviews:

• they can be too frequent
• they can be too drastic

The constant trickle of new information can lead to a vicious cycle of planning and revising which shakes the team's confidence in any particular version of the plan and which destroys the very stability which the structure was designed to provide. You must decide the balance. Pick a point on the horizon and walk confidently towards it. Decide objectively, and explain beforehand, when the review phases will occur and make this a scheduled milestone in itself.
Even though the situation may have changed since the last review, it is important to recognise the work which has been accomplished during the interim. Firstly, you do not want to abandon it since the team will be demotivated feeling that they have achieved nothing. Secondly, this work itself is part of the new situation: it has been done, it should provide a foundation for the next step or at least the basis of a lesson well learnt. Always try to build upon the existing achievements of your team.

Testing and Quality

No plan is complete without explicit provision for testing and quality. As a wise manager, you will know that this should be part of each individual phase of the project. This means that no activity is completed until it has passed the (objectively) defined criteria which establishes its quality, and these are best defined (objectively) at the beginning as part of the planning. When devising the schedule therefore you must include allocated time for this part of each activity. Thus your question is not only: "how long will it take", but also: "how long will the testing take". By asking both questions together you raise the issue of "how do we know we have done it right" at the very beginning and so the testing is more likely to be done in parallel with the implementation. You establish this philosophy for your team by include testing as a justified (required) cost.

Fitness for purpose

Another reason for stating the testing criteria at the beginning is that you can avoid futile quests for perfection. If you have motivated your team well, they will each take pride in their work and want to do the best job possible. Often this means polishing their work until is shines; often this wastes time. If it clear at the onset exactly what is needed, then they are more likely to stop when that has been achieved. You need to avoid generalities and to stipulate boundaries; not easy, but essential. The same is also true when choosing the tools or building-blocks of your project. While it might be nice to have use of the most modern versions, or to develop an exact match to your needs; often there is an old/existing version which will serve almost as well (sufficient for the purpose), and the difference is not worth the time you would need to invest in obtaining or developing the new one. Use what is available whenever possible unless the difference in the new version is worth the time, money and the initial, teething pains.
A related idea is that you should discourage too much effort on aspects of the project which are idiosyncratic to that one job. In the specification phase, you might try to eliminate these through negotiation with the customer; in the implementation phase you might leave these parts until last. The reason for this advice is that a general piece of work can be tailored to many specific instances; thus, if the work is in a general form, you will be able to rapidly re-use it for other projects. On the other hand, if you produce something which is cut to fit exactly one specific case, you may have to repeat the work entirely even though the next project is fairly similar. At the planning phase, a manager should bare in mind the future and the long-term development of the team as well as the requirements of the current project.

Fighting for time

As a manager, you have to regulate the pressure and work load which is imposed upon your team; you must protect them from the unreasonable demands of the rest of the company. Once you have arrived at what you consider to be a realistic schedule, fight for it. Never let the outside world deflect you from what you know to be practical. If they impose a deadline upon you which is impossible, clearly state this and give your reasons. You will need to give some room for compromise, however, since a flat NO will be seen as obstructive. Since you want to help the company, you should look for alternative positions. You could offer a prototype service or product at an earlier date. This might, in some cases, be sufficient for the customer to start the next stage of his/her own project on the understanding that your project would be completed at a later date and the final version would then replace the prototype.
The complexity of the product, or the total number of units, might be reduced. This might, in some cases, be sufficient for the customer's immediate needs. Future enhancements or more units would then be the subject of a subsequent negotiation which, you feel, would be likely to succeed since you will have already demonstrate your ability to deliver on time.
You can show on an alternative schedule that the project could be delivered by the deadline if certain (specified) resources are given to you or if other projects are rescheduled. Thus, you provide a clear picture of the situation and a possible solution; it is up to your manager then how he/she proceeds.

Planning for error

The most common error in planning is to assume that there will be no errors in the implementation: in effect, the schedule is derived on the basis of "if nothing goes wrong, this will take ...". Of course, recognising that errors will occur is the reason for implementing a monitoring strategy on the project. Thus when the inevitable does happen, you can react and adapt the plan to compensate. However, by carefully considering errors in advance you can make changes to the original plan to enhance its tolerance. Quite simply, your planning should include time where you stand back from the design and ask: "what can go wrong?"; indeed, this is an excellent way of asking your team for their analysis of your plan. You can try to predict where the errors will occur. By examining the activities' list you can usually pinpoint some activities which are risky (for instance, those involving new equipment) and those which are quite secure (for instance, those your team has done often before). The risky areas might then be given a less stringent time-scale - actually planning-in time for the mistakes. Another possibility is to apply a different strategy, or more resources, to such activities to minimise the disruption. For instance, you could include training or consultancy for new equipment, or you might parallel the work with the foundation of a fall-back position.

Post-mortem

At the end of any project, you should allocate time to reviewing the lessons and information on both the work itself and the management of that work: an open meeting, with open discussion, with the whole team and all customers and suppliers. If you think that this might be thought a waste of time by your own manager, think of the effect it will have on future communications with your customers and suppliers.

PLANNING FOR THE FUTURE

With all these considerations in merely the "planning" stage of a project, it is perhaps surprising that projects get done at all. In fact projects do get done, but seldom in the predicted manner and often as much by brute force as by careful planning. The point, however, is that this method is non-optimal. Customers feel let down by late delivery, staff are demotivated by constant pressure for impossible goals, corners get cut which harm your reputation, and each project has to overcome the same problems as the last.
With planning, projects can run on time and interact effectively with both customers and suppliers. Everyone involved understands what is wanted and emerging problems are seen (and dealt with) long before they cause damage. If you want your projects to run this way - then you must invest time in planning.

Gerard M Blair is a Senior Lecturer in VLSI Design at the Department of Electrical Engineering, The University of Edinburgh. His book Starting to Manage: the essential skills is published by Chartwell-Bratt (UK) and the Institute of Electrical and Electronics Engineers (USA).

5 - MINUTE MANAGEMENT COURSE

Lesson 1:

    A man is getting into the shower just as his wife is finishing up her shower, when the doorbell rings.

    The wife quickly wraps herself in a towel and runs downstairs. When she opens the door, there stands Bob, the next-door neighbor.

    Before she says a word, Bob says, "I'll give you $800 to drop that towel, "

    After thinking for a moment, the woman drops her towel and stands naked in front of Bob After a few seconds, Bob hands her $800 and leaves.

    The woman wraps back up in the towel and goes back upstairs.

    When she gets to the bathroom, her husband asks, "Who was that?"

    "It was Bob the next door neighbor," she replies.

    "Great," the husband says, "did he say anything about the $800 he owes me?"


    Moral of the story

     If you share critical information pertaining to credit and risk with your shareholders in time,you may be in a position to prevent avoidable exposure.

    Lesson 2:

    A priest offered a Nun a lift. She got in and crossed her legs, forcing her gown to reveal a leg. The priest nearly had an accident. After controlling the car, he stealthily slid his hand up her leg.

    The nun said, "Father, remember Psalm 129?"

    The priest removed his hand. But, changing gears, he let his hand slide up her leg again.

    The nun once again said, "Father, remember Psalm 129?"

    The priest apologized "Sorry sister but the flesh is weak."

    Arriving at the convent, the nun sighed heavily and went on her way.

    On his arrival at the church, the priest rushed to look up Psalm 129 It said, "Go forth and seek, further up, you will find glory."



    Moral of the story
 
     If you are not well informed in your job, you might miss a great opportunity.

    Lesson 3:

    A sales rep, an administration clerk, and the manager are walking to lunch when they find an antique oil lamp. They rub it and a Genie comes out.

    The Genie says, "I'll give each of you just one wish."

    "Me first! Me first!" says the admin clerk. "I want to be in the Bahamas, driving a speedboat, without a care in the world."

    Puff!  She's gone.

    "Me next! Me next!" says the sales rep. "I want to be in Hawaii, relaxing on the beach with my personal masseuse, an endless supply of Pina Coladas and the love of my life."

    Puff! He's gone.

    "OK, you're up," the Genie says to the manager.

    The manager says, "I want those two back in the office after lunch."



    Moral of the story

     Always let your boss have the first say.

    Lesson 4:

    An eagle was sitting on a tree resting, doing nothing. A small rabbit saw the eagle and asked him, "Can I also sit like you and do nothing?"

    The eagle answered: "Sure , why not."

    So, the rabbit sat on the ground below the eagle and rested. All of a sudden, a fox appeared, jumped on the rabbit and ate it.


    Moral of the story

     To be sitting and doing nothing, you must be sitting very, very high up.

    Lesson 5:

    A turkey was chatting with a bull. "I would love to be able to get to the top of that tree," sighed the turkey,"but I haven't got the energy."

    "Well, why don't you nibble on some of my droppings?" replied the bull.

They're packed with nutrients."

    The turkey pecked at a lump of dung, and found it actually gave him enough strength to reach the lowest branch of the tree.

    The next day, after eating some more dung, he reached the second branch.

Finally after a fourth night, the turkey was proudly perched at the top of the tree. He was promptly spotted by a farmer, who shot him out of the tree.



    Moral of the story

     BullShit might get you to the top, but it won't keep you there.

    Lesson 6:

    A little bird was flying south for the Winter.It was so cold the bird froze and fell to the ground into a large field. While he was lying there, a cow came by and dropped some dung on him. As the frozen bird lay there in the pile of cow dung, he began to realize how warm he was.

The dung was actually thawing him out! He lay there all warm and happy, and soon began to sing for joy.

    A passing cat heard the bird singing and came to investigate.

    Following the sound, the cat discovered the bird under the pile of cow dung, and promptly dug him out and ate him.



    Morals of this story

     (1) Not everyone who shits on you is your enemy.

     (2) Not everyone who gets you out of shit is your friend.

     (3) And when you're in deep shit, it's best to keep your mouth shut!


*********