Below you will find ten symptoms of a company that is in dire need of project managementand/or project portfolio management. Read through the list and count how many of these characteristics can be attributed to your organization:

Unexpected issues and problems arise in the middle of projects

Communications seem to be ad-hoc; too often important stakeholders are not informed about key decisions

Priorities of the projects initiated by the executives constantly change, resulting in quick resource reassignments.

There is a chronic shortage of resources at the organization. Employees are constantly complaining about being overworked, while the managers insist that they must roll up their sleeves and work harder

Projects are frequently late and/or over budget and/or do not deliver the full scope promised and the quality of the project product is low

Even if the strategic idea is implemented, the company sometimes fails to achieve the expected improvement or fails to receive any value from the said project at all

The strategic plan – even if the company has one - is presented as a list of projects, but the cause-effect logic tying those initiatives to the company’s mission, goals and the strategy is absent

The list of company projects is not prioritized. Therefore it is assumed that all of these initiatives must be started and implemented more or less simultaneously

Today rather than dispense some valuable project management wisdom, I want to share a major personal frustration of mine … fake job posts. Let me explain what I mean by that. There is a whole bunch of organizations in my city that - due to (I guess) provincial laws - are required to post an external ad every time they have an opening. Even in the scenarios when they have either (a) an internal candidate, (b) former colleague they want to hire or (c) a current friend who they think would be a great fit for this job. As a result, the employer usually follows one of the two scenarios:

Scenario 1:

Create a job description that is so unique that no other person on this planet fits the description.

Example 1.1

“We need an expert-level senior business analyst who is also an internationally acclaimed project portfolio management authority” (Note: it is just like saying “I need a plumber who is also skilled at neurosurgery”)

Example 1.2

“We need a project manager who had at least two ERP implementation projects at Company A in the last three years” (Note: Just how many ERP implementations did Company A have in the past three years? Seven? Eight?)

Example 1.3

‘We need a project manager who also possesses a clinician experience” (Note: Google Dictionary defines “clinician” as “a doctor having direct contact with and responsibility for patients, rather than one involved with theoretical or laboratory studies”. I will let you come up with a joke of your own on this one)

NOTE: None of the above job descriptions are a figment of my imagination! They are very real!

Scenario 2:

Write a normal job description and invite three to seven unsuspecting candidates and then subject them to an excruciatingly boring panel interview. Avoid talking about the project itself, ask a whole bunch of really dumb questions. Thank them at the end. Still hire your former colleague or friend.

PowerPoint – create your status reports in the PowerPoint format. For one they are very easy to project on the wall when conducting stakeholder meeting both at the project and the PMO level. Second, they look attractive; after all PP has been designed as presentation tool!

Length – keep your reports limited to one slide. This approach will help you with selecting the most important information bits about a project. Also, keep in mind the limited attention span of the senior managers. The last thing they want to do is to listen to essays being read out to them at the status meetings (And, yes, I have seen that happen!)

Name and Date – Include the name of the project manager and the date of the report (see Figure 1)

I frequently employ an exercise when teaching my courses; I ask the audience members to think for one moment of their idea of a "dream home". I ask them whether they thought about this before and the majority of them agree that yes, indeed over the course of their lives they have given this topic a lot of thought and can envision this building pretty well.

Then I tell them that they now have to sit down with me - and I am willing to invest as much time as needed - and describe the house to me in detail, down to the type of flooring in the kitchen and living room, colour of the walls in the master bedroom including the exact shade, specific type and model of faucets in the bathrooms, molding in the dining room area, etc., etc., etc. The goal of this exercise is that at the end of it I should have a detailed blueprint of the building and the bill of materials including product SKUs I can go to, say, Home Depot with and purchase all the necessary supplies.

After a couple of minutes someone in the room exclaims,

“But that is impossible! How can you expect us to know all the little details about the house?”

Why am I telling this story? The reason is that thinking that one can easily come up with a complete list of detailed requirements at the beginning of the project is a self-deception. Requirements elicitation is a long and at times painful process of probing, asking questions analyzing the preliminary results, coming up with more questions and investigating again.

Furthermore, once the technical experts sit down to have any kind of requirements elicitation interaction with customers or users, they (the users) do not necessarily provide the analysts with a structured model of requirements that follows a predefined taxonomy. In other words, the customers rarely start these conversations by saying, “I will cover all of the high-level business requirements first, followed by product features. And at the very end I will provide you with all the functions and attributes of the product".

The requirements management domain is by far the most advanced in the technology field where the requirements are (see Figure 1) traditionally broken into:

Business Requirements (or problems, or objectives)

Features (epics in the Agile world) and

Functional and Non-Functional Requirements (user stories in Agile)

Requirements analysts in the IT and software development fields also have tools like use cases, constraints, business rules and data definitions to better define the detailed level requirements.

Here is an example of such hierarchy. Let us assume that a small business producer of, say, scented candles decided at one point that she wants to sell them online. What is the resulting Business Requirement?

BR 1.0 “We need to sell our products online”

Features that naturally flow from it include but are not limited to:

F 1.1 "Customer Login"

F 1.2 “Product Catalog”

F 1.3 “Search Function”

F 1.4 “Shopping Basket”

F 1.5 etc.

The features are later broken into functional and non-functional requirements. For example Feature 1.4 (Shopping Basket) can be broken into the following functional and non-functional requirements:

FR 1.4.x “The user shall be able to add products to the shopping basket”

R: But the client is looking for a Business Analyst, not a Requirements Analyst

Me: But you see, titles like Business Analyst, Systems Analyst, Business Systems Analyst and Requirements Analyst are all synonyms and are used interchangeably depending on the industry and even the company…

R: (sternly) Oh no, unfortunately we can’t send your resume to them. They were very specific in their desire to hire a Business Analyst!

Episode 2 – Conversation with a different recruiter

R: (thoughtfully) So, Jamal, you are a Senior Project Manager, right?

Me: Yep!

R: (inquisitively) But do you have any experience with end-to-end implementations?

Me: Well, by definition, EVERY project is an end-to-end implementation… You have your Initiation, Planning, Execution, Monitoring and Control and Close-out phases. So, every project that has been completed by default went through end-to-end implementation!

On an annualized basis, employers will need to fill nearly 2.2 million new project-oriented roles each year through 2027.

In the U.S. in 2017, wages of project management-oriented workers in projectized industries were far higher on average than wages of non-project-oriented professionals—a premium of 82 percent.

So, if you ever wondered whether to consider project management as your next profession, the time to make the decision is now! Oh, and check out my new online learning platform that can help you to become a project manager, business analyst or a portfolio management expert.

I recently had a very interesting conversation with my much younger colleague. He is also in the project management field but has only five or seven years of experience in our domain. Bob (let us call him that) had his first interview for a PM position at one of the local government organizations. He has been subsequently shortlisted for the second round of interviews and called me up to get some advice.

Bob: (enthusiastically) Jamal, this company is great! I really hope I land a job there!

Me: (apprehensively) And what is so great about it?

Bob: (even more enthusiastically) Listen, they told me a story how they had a problem project that had all kinds of missed deadlines …

Me: (skeptically) And?

Bob: You wouldn’t believe hat happened! One of their vice presidents drove to the construction site and helped unload the trucks. He stayed there for five days straight to assist the workers!

Me: (to myself) Oh, dear God, please take me now! (aloud) Did you ask them WHAT they did wrong to end up in a situation like this?

Bob: (somewhat confused) Oh, yes … it had something to do with improperly calculated lead times … But, as they have indicated, that was not the point of the story! It is the “just roll up your sleeves and work hard” attitude!