ORGANIZATIONAL DESIGN 3/3 - Project Management

 This post is the last of a series of three posts in which we will overview the basic definitions, yet sometimes not so well applied, of Portfolio, Program & Project management.

We focus here on the bottom layer:

 “Project”, like “snow” in Inuit, is ubiquitous in business language. Worse still, everybody seems to work on projects. Yet, the yellow lines between everyday business & project or between program & project are quite clear and passing them brings its lot of [bad] consequences.

In a nutshell, project management means to deliver extra-ordinary (not everyday business output) while aiming consistently at performance. So:

. Gather the ingredients (constraints): features (scope), time, €, quality & risks;

. Choose the tools (organizations involved): the team, customers, suppliers & partners;

. And up the sauce: expedite everything & everyone (integrate).

The recipe seems rather simple yet, like in a kitchen, the recipe does not make the cook.

Furthermore, over the previous years, confusion has grown as branded approaches have been heavily marketed, to milk further the fat cow. Yet, such approaches are just variations of the original:

. Complexity pushes “practitioners” to be more “addicted” to the latest paradigm. Yet, most releases are detailed “advices” almost unusable unless you work in “the ideal-type” organization.

. Simplifications are mostly bypasses to do a quick-&-dirty job or to try to shift power (poor attempt to temporary correct a governance issue).

Rationality helps humans to grasp their environment by simplifying it. As Einstein said, everything should be made as simple as possible, but not simpler. However, customization is easier said than done. Used improperly, it can become poisonous: an Agile approach for a fixed-term contract is devastating: variable scope & fixed terms don’t mix.

Cultural context is important and quite misunderstood. This comes to light in the example of promoting someone to become project manager. The winner generally is:

. In Latin (one may say Catholic) countries, the technological expert close to the product / service;

. In Anglo-Saxon (or Protestant) countries, the sales representative close to the customer;

. In the multi-faceted Asia, the trustworthy subordinate with political acumen.

As perception shapes understanding, one can see the difficulties facing a British project manager with Japanese customers, French engineers and Mexican manufacturing & servicing teams. A hint: IT won’t help much.

Business & Technology contexts are obviously important too. Yet, project management isn’t R&D or engineering; it manages them (among other things). Thus, project management principles remain generally unchanged,  irrespective of sectors.

Still, its application, like the overall organization, will vary depending on what is the most critical between development, marketing & production. So, tailoring must be made.

In B&T contexts, project management acts like a vaccine jab: the organization’s reaction is more a question of company culture than a question of industry.

So, when developing a project management culture, be aware that the B&T-specificity excuse is more a symptom of the devastating NIH(*) virus than a technical hurdle.

(*): Not Invented Here

Project management’s timeframe is very dependent on the technology sold. However, when deviations from standards arise, don’t confuse length with criticality, size with responsibility and float (time margin) with a cushion.

The secret of a successful project management is to keep an active communication towards internal & external stakeholders while leveraging the constraints. Remember, the largest risk in project management (30% of project failures) is a lack of stakeholders’ involvement. Not getting it is a sure recipe to have your project turned upside-down.