The PM Podcast

Project Management for Beginners and Experts


What is a Project? A Simple Question with a Very Difficult Answer


This is a seemingly simple question, at least, for a certified project manager. After all we all know that a project is an “endeavor that has a definite start and an end, undertaken to deliver a unique product a service”. Usually this definition is followed by a couple of illustrative examples:

  • Creation of the first prototype of the Formula One car is a project since it does have a defined start, an end and produces a unique product.
  • Mass production of, say, canned soup is not a project, since while it has a defined start it does not have a defined end. Also, thousands of cans can’t be considered a unique product since all of them are identical.

These examples unfortunately do not reflect the complexities that are usually encountered when deploying project management at various organizations. I remember a consulting engagement when we were working together with a focus group of the employees at a large government organization. One of the tasks on our agenda was to determine what would be considered a project by the company standards and thus require the application of the project management methodology. The following conversation took place between one of the employees and me:

Me: Project is an endeavor that has a definite start and an end undertaken to deliver a unique product a service.

Employee: Wait a second! So, according to this definition the act of sending an e-mail is a project, right? It has a defined start and an end and represents a unique product …

Me: Well, you can look at it this way …

Employee: Does this mean I have to write a project charter, requirements document and a project plan every time I intend to create an email?

Although I appreciated the humor in his inquiry, the “what is a project?” issue is one of the most hotly contested topics during the project management implementation initiatives at almost all organizations. The standard approach is to establish some kind of threshold expressed in terms of dollars or man-months and agree that an endeavor exceeding this threshold would be treated as a project. For example, any initiative with a budget of more than $100,000 (or with an effort of more than 10 man-months) shall be considered a project and will require adherence to the project management methodology.

Discussion of these thresholds usually takes a long time especially at the organizations where metrics gathering is not a very popular practice. Some of the questions that arise are:

  • We do not estimate the cost of our internal projects. How do we apply the threshold rule?
  • We do not estimate or plan the total human effort for our projects. How do we apply the threshold rule?
  • Should we include the human effort required into the overall cost of the project (i.e. do we assume that the employees are free or calculate their daily/monthly cost to the company?)

Another issue that is very frequently brought up is the size of the threshold. Put it too high and the company will end up with too few projects that will require project management methodology. Put it too low and you will discover that you need to hire between 30 and 50 professional project managers!

The way to address these questions is to involve the executives into the discussion and to work closely with the employees of the organization in order to find the optimal solution.

About the Author

Jamal Moustafaev, MBA, PMP – president and founder of Thinktank Consulting is an internationally acclaimed expert and speaker in the areas of project/portfolio management, scope definition, process improvement and corporate training. Jamal Moustafaev has done work for private-sector companies and government organizations in Canada, US, Asia, Europe and Middle East. Read Jamal’s Blog @

If you have a Twitter account, please follow Jamal there:

Like our page on Facebook:

Connect with me on LinkedIn:

Subscribe to my RSS feed:


Write comment (0 Comments)

Managing the Project Resources

By: Brad Egeland

In this article I’d like to address all of the key areas of the project where the project manager is managing the project delivery team, to some degree.  The PM has many responsibilities and tasks of their own, and intertwined with all of those responsibilities is fulfilling the management, education, oversight, watchdog, and communication needs of his own delivery team full of skilled professionals that he now has the responsibility of herding toward a successful end project solution.  There are touch points with the team, of course, throughout the engagement and key responsibilities that go with those, but I’d like to address critical phases or milestones of the project – at least from my own professional experience and perspective – when proper oversight and process was necessary to make sure things were running smoothly for the team, the project, and the customer.

The resource assignment process

Let’s assume the team is assembled by leadership within your organization – that has nearly always been the case from my experiences in professional services organizations.  I’ve been in organizations where one person managed the PMO and assigned PMs to projects based on availability, geographic location, and expertise, and another managed the business analysts and made assignments to projects based on those same considerations.  

The technical staff is usually managed by a development manager or CIO (or both) and the technical resource assignments are made based on availability and expertise and they are often not full project timeline assignments like the PM and the BA are.  Those technical resources are assigned as needed and as determined by the project schedule and resource forecast maintained by the project manager.

Formally kicking off the project

Prior to the project kickoff of the project, the PM distributes all relevant project and contract information to all assigned delivery team members that have been procured to this point.  For me, that has usually only been a business analyst or technical lead – almost never the entire team.  This relevant information and documentation should include, at a minimum:

•    Statement of Work
•    Original resource hours forecast/budget as finalized an account manager when the project was finalized
•    Initial project schedule as created by the account manager for the customer
•    Contact information for project team members on both sides
•    Any relevant travel and expense requirements as mandated by the customer

Prior to formal project kickoff, the project manager and the business analyst are preparing heavily for the formal kickoff meeting with the customer and planning for the move into an exploration and planning phase.  Frequent, adhoc communication is happening at this point to coordinate efforts and ensure that both everyone is on the same page.

Onboarding resources as the project gets underway

Once the formal project kickoff session is over, technical resources will begin being assigned – as needed – to the project and the effort of managing the delivery team resources and forecasting for their usage becomes a more important task for the project manager.  Bringing resources on before they are needed can break the budget, and bringing them on too late can disrupt the project schedule, so careful attention to the needs of the project timeline and tasks is critical.

As new resources are engaged on the delivery team side, four things must always happen…

•    Provide the relevant project/contract docs for review
•    Provide recent status reports and the project schedule for review
•    Provide the resource forecast for review
•    Hold a formal delivery team meeting to go over current status, key project info, and answer questions

Ongoing monitoring and control

As the project moves forward and the project delivery team is fully assembled, then the act of managing the project and resources basically becomes a process of utilizing PM best practices.  Maintaining proper communication and the structure that should already be set in place will help ensure that each team member is up-to-speed at any given time on project status and what is expected of them at that moment and for the upcoming weeks.  This proper communication/structure should be in the form of:

•    Weekly delivery team meetings
•    Adhoc delivery team communication
•    Weekly formal status meetings with the customer
•    Weekly delivery of the revised project schedule
•    Weekly delivery of the project resource/budget expenses and forecast

Write comment (0 Comments)