Articles (506)
0
What is a Project "Schedule"?
Written by Eric Uyttewaal & Murray Woolf
In the world of project management, project schedules can be characterized by their level of sophistication, by their intended usage, or by the nature of their content:
- In terms of sophistication, project schedules range from the simplest (activity listing, timetable), to the more comprehensive (bar charts which converge action with time), to the most complex (network-based schedules, such as CPM, where activities are causally linked).
- Project schedules can also be characterized by their intended uses. Early-phase schedules (more commonly called plans) can be helpful in forging a project execution strategy. Examples of strategic plans include feasibility plans, optimization plan, and consensus plans. Project schedules enjoy their greatest use as tools of communication, coordination, and collaboration. In all cases, project schedules (including precursor plans) are tools of the project manager, intended to optimize their efforts to effectively manage the project.
- The third categorization of project schedules relates to content of the presentation of the schedule. This content is conveyed using adjectives placed before the word “schedule”. Examples are “bar chart schedule”, “milestone schedule”, “submittal schedules”, “design schedules”, “outage schedules”.
Detecting Stakeholder Misalignment
Written by George KonstantopoulosOver the years I have seen many project managers unknowingly accept an engagement that was predicated on an unsupported cause. Usually this misalignment exists between project sponsors (corporate executives etc.) empowered to initiate the project and the business leaders (vice presidents, directors, etc.) and their front line staff assigned to deliver its objectives. The end result is a project manager caught in between opposing beliefs. This article will discuss why it is important to immediately unearth this type of situation during the initiation of the project.
The Trouble with Continuous Multi-tasking
Written by Gareth Byatt, Gary Hamilton, Jeff Hodgkinson
“To do two things at once is to do neither” - Publilius Syrus
Picture the following scenario: you have gone into a “quiet room” such as your office or den to write a long-term program or project plan that you have been meaning to get to for several weeks. The plan requires your full concentration, and it has taken you say three plus weeks to get to because of short-term issues and urgent requests from others that have continually taken priority.
I was working with a large Canadian company recently, helping with their enterprise project management processes. As part of my work, I got to watch while a project control officer prepared a report for the Chief Financial Officer.
It was a work of art.
Requirements - To Detail or Not Too Detailed
Written by Zeena Kabir
In recent years, I have discovered that more and more organizations are writing use cases to clearly understand the behaviors of their systems. Working with these organizations, I usually get the question “What Use Case standard should we utilize?” The answer depends on the project situation. I have utilized two simple use case formats that will help you document use cases in some of the following common situations:
The following is an excerpt from the book Practitioner's Guide to Requirements Management, Part I: Requirements Planning written by the authors.
Overview
Requirements management, like project management, is a discipline comprised of inputs and outputs, tools, and techniques, processes and activities, but just for the business analysis effort. Requirements management includes the planning, monitoring, analyzing, communicating, and managing of those requirements. Get a quick introduction or refresher on this important topic.How Bad Project Managers are Killing the Profession
Written by Jim Hannon
I often sit in meetings and either being the PM or the development manager I see eyes roll when you discuss project management. This response is sometimes baffling and also is somewhat warranted in certain cases. In this article I will attempt to lay the groundwork on why there is an internal destruction of the project management profession by some of it own members and what we can do about it.
The Case Against Project Portfolio Management
Written by Vilmos Rajda
Until recently I belonged to the wide-eyed crowd who was excited about the prospects of project management’s new silver bullet: Project Portfolio Management (PPM) software. Hordes of slick sales people from various PPM software vendors, will talk to you about the infinite value of applying their solutions. They will show you rainbow coloured bubble charts, black belt project prioritization features and six sigma resource management functionality. If you are not convinced by the end of their demo, then you probably do not own a cell phone that can make French toast (i.e. living in a cave), or you are a project neophyte who is just not getting it.
Managing a Virtual Project Team
Written by Gary Hamilton, Jeff Hodgkinson, Gareth ByattLet’s face it; virtual teams (where we work with colleagues in remote locations, be they close by or in different countries) are now a reality in the workplace. If this trend in the workplace environment continues, virtual working will increasingly influence the way we operate, and the ‘effective virtual team worker’ will be a valued asset. A key benefit to forming virtual teams is the ability to cost-effectively tap into a wide pool of talent from various locations. There are several definitions of the virtual team worker, but within the context of this article, we are talking about people who work on project teams and who display the following attributes:
It is with deep sadness that we inform you that Ollan Delany, our long-time friend and dedicated editor of ProjectTimes and BA Times, passed away on Sunday of colon cancer. Ollan was 68.
Ollan was an easy going and happy person who excelled in the Publishing industry. He was integral in developing content since the inception of both ProjectTimes and BA Times.
Ollan developed outstanding relationships with many key thought leaders in the PM and BA community and is a big reason for our success in presenting, the larger PM & BA Community, with timely and relevant content.
Ollan joined our ProjectTimes team within the first two years of publication (1998). He knew nothing about project management but everything about the English language and the written word. It took him very little time to figure us out and in turn became indispensible to us.
If you are interested in making a donation to The Cancer Society in Memoriam of Ollan, you can do so HERE.
Our deepest condolences to Ollan's family. Farewell dear friend. We miss you already.