Four Techniques to Manage Your Schedule

You will never be a successful project manager if you do not know how to build and manage a schedule. The schedule may be the most fundamental tool for managing projects. Here are four techniques to help you take full advantage of the project schedule.  


  1. The remainder of the schedule is the most important

The schedule should represent your best-guess at any particular point in time on how to complete the remaining work. The more complex your project is, the more change is going to be required in your “best guess” over time. The project manager must evaluate the schedule on an ongoing basis and determine the current state of the project. Based on the current state of the project, and your current understanding of the work remaining, you need to re-plot a course that will allow the work to be completed within the original budget and deadline.

  1. Update the schedule weekly

For most projects, the schedule will need to be reviewed on a weekly basis. During this review, the project manager updates the schedule with the current state of work that is completed and in-progress. The remaining work should be evaluated to see if the project will be completed within the deadline. If it can, you are in good shape. If it cannot, the project manager must implement corrective action.

  1. Proactively manage schedule variances

The project manager may be in a position of having to constantly utilize his experience and creativity to get the project completed within expectations. One week your project many be on track. The next week, you may have work assignments that are late and issues that have surfaced. If you are good at it, managing the schedule can be one of the more challenging and rewarding aspects of project management. If you do not relish the detailed work that is required, you may find it much more difficult to be successful as a project manager.

  1. Validate who can update the schedule

On most projects the project manager is the only one that is allowed to update the schedule. However, there are other options, especially for larger projects. The project manager may ask each team member to update the schedule with actual hours worked, remaining hours and proposed end date. For very large projects, it is also common for one or more people to be assigned to update the schedule on behalf of the project manager. These people are sometimes called project administrators, project coordinators or project schedulers. They can get information from team members and update current status and actual hours worked. They bring this all to the project manager for final analysis and evaluation.


Five Strategies for the Responding to Risks

Identifying risks is only the start of the risk management process. If you identify a risk you are obligated to create a risk plan to respond to the risk. You should create a risk response for all “high” risks. There are a number of general options that the project manager should consider for responses.


1)      Leave it. In this approach, the project manager looks at a high risk and decides to do nothing. This can happen for one of two reasons.

a)      First, the project manager may feel that cost and effort of managing the risk is more than the impact of the risk event itself. In this case you would rather deal with the costs of the risk occurring that the cost of trying to manage the risk.

b)      Second, there may not be any reasonable and practical activities available to manage the risk. For instance, it is possible that there is a risk of your sponsor leaving and a new sponsor canceling the project. However, you may not be in a position to do much about it as long as the current sponsor is in place, and you may just need to leave it and see how events play out.

2)      Monitor the risk. In this case, the project manager does not proactively manage the risk, but monitors it to see whether it is more or less likely to occur as time goes on. If it looks more likely to occur later in the project, the team must formulate a different response at a later time. This is a good approach if you have identified a risk that should be managed, but the risk event is far off in the future.

3)      Avoid the risk. Avoiding the risk means that the condition that is causing the problem is eliminated. For example, if you find that a part of the project has high risk associated with it, that whole part of the project can be eliminated. The risks associated with a particular vendor, for instance, might be avoided if another vendor is used instead. This is a very effective way to eliminate risks but obviously can be used only in certain unique circumstances.

4)      Move the risk. In some instances, the responsibility for managing a risk can be removed from the project by assigning the risk to another entity or third party. For instance, you may identify a risk associated with a new technology. Outsourcing the function to a third party might eliminate that risk for the project team. The risk event is still there, but now some other entity is dealing with it.

5)      Mitigate the risk. In most cases, this is the approach to take. Mitigating the risk means that you put in place a set of proactive steps to minimize the likelihood that the risk will occur. If possible you could eliminate the risk by minimizing the likelihood down to zero percent. Another purpose of mitigation is to ensure that if the risk occurs, the negative impact of the risk is minimized. In many cases it may not be possible to totally eliminate a risk event, but given that you have time to prepare, you should be able to minimize the probability of the event occurring, or minimize the impact to the project if the risk event does occur.

These are typical risk responses for negative risks. You can first identify one or more risk strategies and then put the detailed activities in place to effectively manage the risk.

Six Options When Managing Projects With Unrealistic Deadlines

If you are a project manager dealing with what you perceive to be an unrealistic deadline, the first thing you will want to do is talk to your sponsor to see if there are any business factors that are driving the deadline. For example, there may be some event occurring that this project needs to support. On the other hand, sometimes managers set arbitrary end-dates just to provide what they consider to be stretch objectives. You may find that by better understanding the reason for the deadline, you may have an easier time getting the team motivated to achieve it.


Once you understand the cause for the deadline date, there are project management techniques that can be utilized to increase the chances of success.

1)      Increase resources.

If you find that the deadline is not in alignment with your resources, talk to your manager about increasing the resources that are available for the project. Adding resources to the project may increase the cost, but may allow you to hit the deadline. If the deadline is most important this may be a viable option.

2)      Reduce scope.

Talk to your sponsor about reducing the project scope. See if there are features and functionality that he can live without for now so that you can deliver the project within the deadline specified.

3)      Identify and manage the deadline as a project risk.

Utilizing risk management will help better manage expectations early in the project and also be a way to gather input and ideas for ways that you might be able to hit the deadline.

4)      Manage scope with zero tolerance.

On many projects, you start with an aggressive delivery date, and then the situation gets worse because you do not effectively manage scope. It is absolutely critical that you manage scope effectively and do not increase scope without an appropriate increase in budget and timeline.

5)      Manage the schedule aggressively.

In many projects, you might get a little behind but have confidence that you can make up the time later. However, when you start a project with the deadline at risk, be sure to manage the schedule diligently. You have no margin for error. As you monitor the schedule, treat missed deadlines as problems and work hard to solve the reasons behind the slippage.

6)      Look for process improvement opportunities.

Lastly, take a hard look at your schedule and your approach for executing the project. Talk to your team, clients, and manager about any ideas they may have for making the project go faster. This will get everyone thinking about being part of a solution.

Although it appears that you are being held accountable for events and circumstances that are not within your control, you do have control over the processes you use to manage the project. Use them proactively and wisely.


Was Your Project Successful – Within Tolerances?

Estimating the time and cost is an important part of project planning. If you estimate a project to cost $230,000, is your project a failure if the actual cost is $230,500? You missed your budget, right? Yes, but this gets into the concept of tolerances. If you delivered within $500 on a $230,000 budget, you should be lifted on your manager’s shoulder and paraded around the company as a hero.
Your company needs to establish the tolerance level that they consider to be reasonable for projects. For example, the tolerance level may be -10% to +10%. That is, if you deliver the project 10% over budget, it is still considered a success. For the $230,000 project, that means you could have gone overbudget by $23,000 and still have been considered successful.
Normally there is some room for tolerances with your deadline as well. In most cases, you can deliver a little late and still be considered successful. Of course, not all projects have that flexibility. Some projects do have a fixed end date that cannot be moved. But many projects have some flexibility.

project success

Declaring Success From a Project Perspective

Once you understand your tolerances (if any), you can start to evaluate success from a project perspective. Generally, the project team members can declare success if:
1) The project is delivered within the estimated cost, plus or minus the tolerance.
2) The project was delivered within its deadline, plus or minus the tolerance.
3) All of the major deliverables were completed. (Some minor ones, or minor functionality, might not be delivered.)
4) The overall quality is acceptable. (It does not have to be perfect.)
Other factors may be important for specific projects. For instance in a construction project, safety might be a key success component.

Declaring Success from a Company Perspective

From a company perspective, success is also based on whether the company received the business value that was promised. There are many examples of projects that were completed successfully, yet are not delivering the value promised. It is possible that the return on investment calculations were faulty, or the marketplace was misjudged by the sponsor. We believe that success against the project business value, as defined in the Business Case, is ultimately the responsibility of the sponsor – not the project team.

Utopia on Earth. Is it possible?

Would you like to live in a better world? Mankind has spent millennia looking for a perfect society—a utopia—where all can live in peace and happiness. Why has it always gone wrong? Will we ever have utopia on this earth?


A utopia is a community or society possessing highly desirable or perfect qualities. The word was coined by Sir Thomas More in Greek for his 1516 book Utopia, describing a fictional island society in the Atlantic Ocean. The term has been used to describe both intentional communities that attempt to create an ideal society, and imagined societies portrayed in fiction. It has spawned other concepts, most prominently dystopia.

The word utopia was coined in Greek by Sir Thomas More for his 1516 book Utopia, describing a fictional island society in the Atlantic Ocean. The word comes from the Greek: οὐ (“not”) and τόπος (“place”) and means “no place”. The English homophone eutopia, derived from the Greek εὖ (“good” or “well”) and τόπος (“place”), means “good place”. This, because of the identical pronunciation of “utopia” and “eutopia”, gives rise to a double meaning.

On which ground shall we start an utopian view of paradise on earth? Shall we erase our experiences as human beings or shall we preserve them as the pillars of this utopian dream?

I wish to say that life is… imperfect. Therefore, we can only approach the topic from a human point of view. Desire is the cause of imperfection and utopia is the fulfilment or transmutation of this desire to unify, to harmonize…

Less desire, then less craving, then less ego and selfishness….it is always difficult to eliminate desire. Desire create ambition and ambition create action for growth. This make it hard…to progress and evolved, desire is needed. Can humanity still achieve utopia alongside with technological and economic progress?

For thousands of years, philosophers have debated: What would a perfect world be like? How would it come about? Yet, in spite of all their ideas and efforts, human beings have not been able to create a perfect world. Why not? Has Utopia failed—or is it even possible?

Seven Steps to Manage Stakeholder Expectations

You performed an initial stakeholder analysis when you defined and chartered the project. The stakeholder analysis should also be updated periodically to ensure that the stakeholders are being engaged successfully. If the stakeholders are not being engaged as you wished, you should update or change your activities. It is possible that you will also discover new stakeholders as the project progresses, and they should be accounted for in this process as well.


  1. Establish an agreement. This is probably the most overlooked yet most obvious piece. It is difficult or impossible to manage stakeholder expectations if you do not have some agreement to begin with. You need to agree on what the expectations are. 
  2. Manage change. Once an agreement has been reached, changes should be managed through the change management process. This ensures that the stakeholder approves all changes and helps keep expectations in line.
  3. Communicate proactively. When the agreement has been reached, continue to communicate proactively through the status reporting process or as part of a broader Communication Management Plan – especially if there are any problems meeting the expectations. This helps the stakeholder keep up-to-date on progress, issues, risks, etc. The main motivation is to avoid surprises.
  4. Periodically assess performance. The project manager should be assessing expectations on an ongoing basis. If it looks unlikely that you will meet expectations, immediate steps should be taken to get back on track.
  5. Deliver against the expectations. Again, this may seem obvious. However, once an agreement has been put into place, you need to make sure that you deliver as expected. One of the weaknesses on the part of many people is that they do not fulfill their agreed-upon expectations, and they do not communicate with the stakeholder to inform them of the status and acknowledge the missed expectation.
  6. Reset expectations if necessary. If you determine that the original agreement cannot be satisfied, the agreement should be re-negotiated. This process includes gathering the facts surrounding the inability to meet the original agreement. In addition, alternative courses of action should be formulated to determine how to perform as closely to the original agreement as possible in a way that will satisfy both parties. Once a modified agreement has been reached, reset the expectations and begin the work necessary to meet the requirements of the new agreement.
  7. Complete the agreement. Review the completed work with the stakeholder to ensure that the terms of the agreement have been fully met. If not, negotiate what will be required to fulfill the agreement.

The project manager should ensure that the stakeholders are involved in the project and that the expectations of the stakeholders and project manager are always aligned. Then manage the expectations and achieve the commitments.

Ten Components for Integrated Change Control

Scope changes have an impact on the project. The impact can be greater than just schedule and budget. In many cases, it may be hard to understand the nature of a change and the impact to the various aspects of the project. For example a change request can come into the project that results in a change to scope. The scope change request may lead to a request to increase schedule and budget. The request might impact the types of resources that are needed on the project ands it might effect a vendor contract. The change could introduce additional risk. The project manager needs to understand the nature of the change and how it might impact all other aspects of the project.

changes aheadIntegrated Change Control is a way to better understand the nature of scope changes. Integrated change control includes the following.

1. Making sure there are baselines in place (scope, budget, schedule, etc.) so that it is more obvious that a change has occurred.

2. Looking at the causes of change to see if the causes can be (or should be) eliminated. For instance, if you believe you are receiving too many scope change requests, it may reflect on a poor requirements gathering process.

3. Making sure no changes are implemented unless they have been approved.

4. Making sure there are processes in place to manage change. The level of formality of the approval process increases with the size of the project and the size of the potential change.

5. Making sure the entire project team, including the customer, understands the change management processes and follows them.

6. Making sure the appropriate documentation is created and saved for each change.

7. Understanding how changes impact all related aspects of the project.

8. Making sure that there is a person or body available to approve or reject all change requests.

9. Making sure all change requests are closed by either an acceptance of the change or rejection of the change.

10. Communicating changes and the impact on the project to the appropriate stakeholders.

Integrated change control provides a more holistic look at scope change across the entire project environment and can help projects be more successful – especially large projects.

Review Eight Aspects in a Feasibility Study

Most people are aware of a Business Case. The Business Case allows you to define a project at a high-level, yet with sufficient enough detail to know whether the organization wants to provide funding. However, sometimes the sponsor is not certain of the costs and benefits, or even if the project is feasible. This is a good time for a Feasibility Study.

A Feasibility Study is used to explore whether a project makes sense or not. The Feasibility Study looks at more than cost and benefit. It looks at whether the project is feasible in a number of areas.


There are a number of areas of feasibility that should be analyzed.

1.Technical. Is the project technically feasible? If it is you should state any technical risks associates with the project.

2.Financial. Is the project financially feasible? This would be especially important if the cost of the project was material to your company. It is possible that a project could have a cost that is significant enough to put the entire company at risk. You may have the ability to budget for the project now, but you might also analyze what the impact would be of a significant cost overrun.

3.Operational. Can you operate the project solution? It is possible that the project itself is feasible, but you may have significant risk in being able to operate the solution after the project is over.

4.Geographic. Is the project feasible given the physical location of the project team or the customer?

5.Time. Is the project feasible given the amount of time it will require from the participants? This is a big worry on larger projects. You may have the budget to execute the project but you may realize you cannot free up the project team for enough time to execute the project.

6.Resource. Do you have the staff, equipment, supplies and other resources necessary to complete the project?

7.Legal. Are there any legal problems that will make this project unfeasible?

8.Political. Are there any internal (or external) political problems that will make this project unfeasible?

Recommendation. You may explore a number of alternatives for structuring the project before ultimately drawing your final conclusion and recommendation. The recommendation may be that the project is not feasible. The sponsor and management stakeholders may choose to accept the recommendation or move another direction.

If the project appears feasible, the sponsor would proceed to develop the Business Case based on the final recommendation. The Business Case should address the costs, benefits, risks, assumptions, and other information to finally determine if the project makes business sense.

My favourite movie is Cloud Atlas

The film consists of six interrelated and interwoven stories spanning different time periods. The film is structured, according to novelist David Mitchell, “as a sort of pointillist mosaic.”

Cloud Atlas

South Pacific Ocean, 1846

Adam Ewing, an American lawyer from San Francisco, has come to the Chatham Islands to conclude a business arrangement with Reverend Gilles Horrox for his father-in-law, Haskell Moore. He witnesses the whipping of a Moriori slave, Autua, who later stows away on the ship. He confronts Ewing and convinces Ewing to advocate for him to join the crew as a freeman. Meanwhile, Dr. Henry Goose slowly poisons Ewing, claiming it to be the cure for a parasitic worm, aiming to steal Ewing’s valuables. When Goose attempts to administer the fatal dose, Autua saves Ewing. Returning to the United States, Ewing and his wife Tilda denounce her father’s complicity in slavery and leave San Francisco to join the Abolition movement.

Cambridge, England and Edinburgh, Scotland, 1936

Robert Frobisher, a bisexual English composer, finds work as an amanuensis to aging composer Vyvyan Ayrs, allowing Frobisher the time and inspiration to compose his own masterpiece, “The Cloud Atlas Sextet.” While working for Ayrs, Frobisher begins reading the published chronicle of Adam Ewing’s journal which he has found among the many books at Ayrs’s mansion. He never finishes reading the journal and notes in a letter that “A half-finished book is, after all, a half finished love affair.” When “The Cloud Atlas Sextet” is revealed to Ayrs, he wishes to take credit for Frobisher’s work, claiming it is the result of their collaboration and threatens to expose his scandalous background if he resists. Frobisher shoots and wounds Ayrs and flees to a hotel. Perhaps spurred by his inability to complete Ewing’s book, he finishes “The Cloud Atlas Sextet”, then commits suicide, just before his lover Rufus Sixsmith arrives.

San Francisco, USA, 1973

Journalist Luisa Rey meets an older Sixsmith, now a nuclear physicist. Sixsmith tips off Rey to a conspiracy regarding the safety of a new nuclear reactor run by Lloyd Hooks, but is assassinated by Hooks’ hitman Bill Smoke before he can give her a report that proves it. Rey finds and reads Frobisher’s letters to Sixsmith, resulting in her tracking down a vinyl recording of Frobisher’s “The Cloud Atlas Sextet.” Isaac Sachs, another scientist at the power plant, passes her a copy of Sixsmith’s report. However, Smoke kills Sachs by blowing up the plane in which he is flying, and later also runs Rey’s car off a bridge, but she is able to escape. With help from the plant’s head of security, Joe Napier, who knew her father, she evades another attempt against her life which results in Smoke’s death and exposes the plot to use a nuclear accident for the benefit of oil companies.

United Kingdom, 2012

65-year-old publisher Timothy Cavendish reaps a windfall when Dermot Hoggins, the gangster author of Knuckle Sandwich, publicly murders a critic who gave the novel a harsh review. When Hoggins’s brothers threaten Cavendish’s life to get his share of the profits, Cavendish asks for help from his wealthy brother Denholme. Avenging an old affair with his wife, Denholme tricks Timothy into hiding in a nursing home, where he is held against his will and abused by the head nurse, Noakes. While there, Cavendish reads a manuscript of a novel based on Luisa Rey’s story. Plotting with three other residents, Cavendish escapes and goes on to write a screenplay of his story.

Neo Seoul, (Korea), 2144

Sonmi~451 is a genetically-engineered fabricant, a human clone and slave worker living a compliant life of servitude as a server at a fast food restaurant. She recounts her memories before an interviewer, an archivist whose purpose is to document her thoughts and story for the future. Sonmi begins by recounting a day in the life of a fabricant like herself. She tells how she was exposed to ideas of rebellion and liberation (based on Cavendish’s adventures), and how she was rescued from captivity by Commander Hae-Joo Chang, a member of a rebel movement known as “Union”. He smuggles her to a residence in Neo Seoul where he exposes Sonmi to the larger world, including the banned writings of Aleksandr Solzhenitsyn and a film version of Timothy Cavendish’s “ghastly ordeal”. They are found and Sonmi is captured. Hae-Joo rescues her, introduces her to the leader of the rebel movement, then shows her that fabricants are not freed at the end of their contract as she believed, but are killed and “recycled” into food for other clones. She decides that the system of society based on slavery and exploitation is intolerable, and makes a public broadcast of her story and manifesto. Hae-Joo is killed in a firefight and Sonmi is captured again. After telling her story to the archivist, she is executed.

The Big Island, 2321

(This section is dated “106 winters after The Fall” in the end credits and book cited as 2321.) Zachry lives in a primitive society called “The Valley” after most of humanity has died during “The Fall,” a largely-unexplained apocalyptic event. The Valley tribesmen speak a degenerated form of English, and worship a goddess called Sonmi (Sonmi~451), their sacred text taken from the broadcast of her manifesto. Zachry is plagued by hallucinations of a demonic figure called “Old Georgie” who manipulates him into giving in to his fears. One day, Zachry, Adam (Zachry’s brother-in-law)and Zachry’s nephew are attacked by the cannibalistic Kona tribe. He runs into hiding and watches as his companions are murdered. His village is visited by Meronym, a member of the “Prescients”, an advanced society still using the last remnants of technology. Her mission is to find a remote communication station called Mauna Sol and send a message to Earth’s off-world colonies. Catkin, Zachry’s niece, falls sick, and in exchange for saving her, Zachry agrees to guide Meronym into the mountains to find the Atlas. At the station, Meronym reveals that Sonmi was not a deity as the Valley tribe believes, but a normal human who died long ago. After returning, Zachry finds his tribe dead, slaughtered by the Kona. He kills the Kona chief, rescues Catkin, and Meronym saves them both from an assault by Kona tribesmen. Zachry and Catkin join Meronym and the Prescients as their ship leaves Big Island.

Prologue / Epilogue

A seventh time period, several decades after the events on Big Island, is featured in the film’s prologue and epilogue: Zachry is revealed to have been telling these stories to his grandchildren on a beach near a city on an extraterrestrial Earth colony. The epilogue also confirms that Meronym succeeded in sending the message and traveled to the off-world colony where she lives with Zachry.

Project Managers Have Process and People Responsibilities

What does it take for the project to be a success? If the project has any kind of complexity you need a good project manager. To be successful, a project manager should have great skills for managing the project management processes, and for managing the people on the project.

The project management processes include:

  • Planning, estimating and structuring the work and the project

  • Building and managing a schedule to ensure work is identified, assigned and completed on time

  • Estimating and managing the project budget

  • Identifying, tracking, managing and resolving project issues

  • Proactively managing scope to ensure that only what was agreed to is delivered, unless changes are approved through scope management

  • Proactively disseminating project information to all stakeholders

  • Identifying, managing and mitigating project risk

  • Ensuring that the solution is of acceptable quality

  • Managing vendors to ensure all third-party work is completed within expectations

  • Identifying and engaging project stakeholders

Remember, this does not mean that the project manager physically does all of the work, but he must make sure it happens. If the project has issues or scope creep, or faces risks, or if expectations are not set correctly, the project manager is the person held accountable.

To manage the project management processes, a person should be well-organized, have great follow-up skills, be process-oriented, be able to multi-task, have a logical thought process, be able to determine root causes, have good analytical ability, be a good estimator and budget manager and have good self-discipline.

People management

In addition to process skills, a project manager must have good people management skills. This includes:

  • Having the discipline and management skills to make sure that everyone follows the agreed processes and procedures.

  • Leading people so that they willingly follow your direction. This includes communicating a vision and getting the team to strive to get there.

  • Setting reasonable, challenging and clear expectations for people and holding them accountable for meeting the expectations.

  • Team-building skills so that the people work together well, and are motivated to work hard for the sake of the project and their other team members.

  • Communicating proactively using good verbal and writing skills, and active-listening skills.

The project manager is responsible for managing the staff on the project. This is usually a shared responsibility with the team member’s functional manager.