The Perfect Project (Manager), Part I

five person by table watching turned on white iMac

Introduction project management

How to implement the perfect project? Or better and more specific, the perfect IT project?For answering this in more details, it's a good idea to determine if there are problems with project management in general (as the strong rumors are to be believed). There are.The rate of failure in Project Management (worldwide) is about 69%. IBM failure goes to 70%. In Israel, the failure of IT projects is almost 100%.Why? Well, there were individuals (and several organizations) who went out to investigate the reason for such high level of failure. In general, they agreed on the common factor of failure and that was the faulty requirements.Is that true? FYI, a general IT project contains several parts:

  1. Design

  2. Scheduling

  3. Implementation

  4. Post-project handling

(many projects contain more parts, but this depends on the project and its subject)

The design is the phase, which contains multiple parts as well.

  1. Requirements

  2. Functional specifications

  3. Technical specifications

  4. Optionally the task list (I always prefer working like that as the prefect of the scheduling).

(Don't get me wrong, the ultimate intention of the design process are the design documents. But before those documents can be written, you will need to go through the processes of design).

As we can see, if the requirements 'might' be faulty, they miss the other very important parts of the design: the functional and technical specifications. Without it, you have the guaranteed failure of a project. And those parts will have many other sub-parts as well.

Anyway, as I have already mentioned the several parts, this is the way how to do a successful project

.

Who or what is a Project Manager?

person working on blue and white paper on board

That's not easy to define. I mean go to Google and get their definition of a project manager, but if you so, the project is likely to fail (70% or more chance of failure!).

Google says: A person in overall charge of the planning and execution of a particular project. Such person is the one, who has the overall responsibility for the successful initiation, planning, design, execution, monitoring, controlling and closure of a project. ... Most of the issues that impact a project result in one way or another from risk. 

It says nothing about the type of person. Let's see. My mother could be the perfect project manager. Not my father, because half of an average project team ends in a painful way.What's the best description of the type of person a project manager must be? An administrator, leader, teacher, intelligent, experienced and knowledgeable. His or her mindset must be that such person goes over dead bodies if needed. A person who can handle extreme authority and the heavy, lonely burden of leadership and willingly to take on the responsibility of the job.

Mostly (or alternatively the best) it’s a person, who’s not married (otherwise most of them will divorse), middle aged and able to read (and write) loads of pages of text. It’s a person with high salary, working 15-18 hours a day, 365 days a year.Without such person, the project will fail. It's as simple as that.And if you want to know my professional opinion why so many projects fail? It's always the project manager, not some stupid faulty requirements going sour or some faulty computer or a bad manager.

Organization structure

In the past, those people working in office were formally dressed (suites with ties and the like). Today that's differently. You see many times the general manager of a large company popping up at work in fainted jeans and torn t-shirts, parking his motorcycle somewhere.I'm not going discuss the variations and types of organization structures like the pyramids or flat-organization structures, no, I'm talking about projects and there are always pyramid-types of organization structures. Failing to do so means failure of your project.A project manager is the absolute ruler of his or her (project) organization. His or her word is the law. He or she is responsible for everything, ranging from the electricity to the toilet paper, from the coffee to the secretary, from the windows to the weather, from your car to the dress your wife is wearing. And that stays so as long as the project is active.If it rains, it's the fault of the project manager. From your car running our of gas or the fight with your husband at home in the middle of the night, it's the fault of the project manager. If the electricity breaks down at the office, or someone ate all the sweets, it's the fault of the project manager. He or she has the full responsibility.If the project manager enters the room with project members, everyone freezes. His authority is absolute, and the project manager shows that power easily. He works from a large office, works alone in principle (except those with PM assistants), dresses (semi-)formal, doesn't show much emotion and his workday is 15-18 hour a day. He or she's the first in the office and is the last when he or she leaves for home. When the PM is at home, the PM thoughts are with the project.

The Project management blocks

 

grey and black pen on calendar book

First of all, project management (globally) is divided into several parts:

  1. Design

  2. Scheduling

  3. Implementation

The most important part of a project is the design. The design is an actual separate part of the project and it might be even used to sell it separately.

The design is a process. A set of methods and activities, which leads to several final (legal) documents, which are everywhere referred to each other.

Requirements

For example, the requirements. The requirements is a phase in the design part of the project and for most projects, such process is unique. In order to have requirements, you need to have a customer. If there are no customers, you have a problem. 

I still remember the time I was attempting to make a requirement document in the form of a monologue with myself. It went dreadfully and classically wrong of course. In those cases, the requirement phase would be expanded with a business plan.

Requirements is not a single document. It can lead to multiple media, like recordings, videos, prototypes, paintwork, artwork, many studies in PDF or any format, etc. Its a process.

Assuming that you have a customer, you start the process with meeting with them. When this phase starts, I meet the customer with the QC manager, the graphical designer (who can draw on the spot), a secretary (or someone who can take notes and take care of the administrative parts of the process) and if needed, more people of different disciplines (for example, if the project is about a scientific subject or a specific industrial process, you take your own specialist with you, or a GUI designer, who can create phony (prototype-like) applications for perspective, etc.).

Why the graphical designer? If you don't want to have a prototype build, use the graphical designer, who can create GUI designs about the points the customer is making. The issue of expectations is one of the biggest problems in R&D. Its quite possible that the customer visualizes something total different then the R&D is developing.

I was involved in huge projects, which took years to complete. After the presentation of the finished product, the customer was speechless for a while, totally shocked. At the end he said that this was not what he meant.

Why the QC manager? It's the trick to reduce expected defects to make. The QC manager is the one involved in the beginning of the project. For a person like that, the customer is holy, because that's the actual source to determine that the future project is doing exactly as is expected. His or her main task is to build the framework of avoiding and detecting defects or bugs and to control them ... and not to forget to predict them.

Why the GUI programmer? The customer is referring to screens or processes, where their people entering data into the system and the GUI programmer is making dummy screens with all the details the customer need and produces examples of reports.

Why the secretary (or an advanced administrative help)? Meeting minutes, recording, meeting reports, who is present, sending status updates to each other relevant to the process, etc. A person like this will organize (and in some cases lead) the requirements phase. Such person is essential. Without the secretary, with large projects, they will fail without any question.

Why the project manager? Well, he or she is essential for the project and must be actively involved in any aspect of the project from the beginning till the end. The PM is responsible for the end product, for the project processes ... actually the project manager is responsible for everything during the project, even responsible up to the type of underwear his project members are wearing.

I like to record everything in this phase. I record or film the process from the beginning till the end. Also I like to state in the beginning of the requirements process that the process will be completed with a final requirements document (and its many attachments) and a legal agreement, signed by all relevant and involved parties. (I really want to see the situation arriving that at the end the customer is playing surprised and claim that this is not what he or she didn't expect the end product to be). The legal agreements avoid such bottlenecks.

Many requirement phases of many different projects throughout my career produced many sub-studies and/or documentations and/or sub-products. For example I had projects, which had an advanced and detailed study of the GUI of the project, taking care of the expectations problem of the customer, and it helped of course with the data design and the program flow, etc.

And doing such process, there are always the common problems with the requirements, that the customer doesn't have any idea what he or she wants. Or worse, the customer knows, but it's not possible to do such thing, money or not. For example, when the customer wants to have an airplane developed, which flies 10 times the speed of light and that in pink. It's a process, as I mentioned it already multiple times and that means that nobody might predict what effort the requirement team must make in order to produce the requirements.

In some cases, it's possible that the project manager will discover the logical errors or the feasibility of such requirements in a later phase of the project (i.e. in the technical specifications). Be prepared for that and let the customer know that this is possible and in some cases expected.

And finally, at the end of the requirement phase, you have an acceptance meeting, which is filled with everyone involved, the final presentation(s) and the lawyers with the contracts about the work everyone has performed.In the past, I was forced to organize events to improve the process of requirements. In order to get the people working for the customer to open up, I organized a barbecue with their families and guess what? In the evening of that event, assisted by their wives and husbands and some wine and beer, I got the information I needed. The next day the requirement process was suddenly much more productive and finished in a record time.

This completes the first part of the article. There is the second part, “The Perfect Project (Manager), Part II”.