Project Management

What is Project Management?

Project management is the discipline ofplanning, organizing, securing, managing, leading, and controllingresources to achieve specific goals.

In Israel, some of the bold keywords above here are a bit problematic. Words like discipline, planning, managing and leading are … well; I (still) have no words for that, I think you need to experience it.

Let me expand to the definition of Project Management and take each component as see what it really is.

Before that, there are some remarks I want to place about Project Management in general.

• I really dislike situations, where RND managers andSoftware managers are hiring young officers from the army and declare them project managers, because, they think, they are officers and used to manage people, so they are project managers. In my view it is an insult of the functionProject Manager. It’s also a waste of company resources and those managers suppose to be fired as incompetent. They can better hire some person from the street, like a homeless person; it has the same result, only more amusing.
• A project manager is a manager. A manager is firstly an administrator, then a teacher and then a leader and in exactly that order and not different. The project manager is responsible for a group of people with a common goal in a temporaryorganization.
• A project manager is defined by knowledge and expertise, and not some political appointee or some wishful thinking.
• And before I forget, a real project manager is highly paid, more so then the Software Manager.

Planning

Planning Process Group (Photo credit: Wikipedia)

Planning here is a term, which is used loosely. It’s a process of design, which can contain several sub-stages:

1. Requirements
2. Design
3. Plans
   1. Project
   2. Acceptance
   3. Implementation

This process is carefully designed in a way, that each component integrates (and refers) within each other into the last details of each stage.

And not only that, a real project manager is designing the process here in a way, that there is a fail-safe entity included. For example the requirements, which is the phase what is the building stone or foundation of the project. Within the requirements, a good project manager includes the QC (Quality Control), which task (in that stage) is to guarantee that the rest of the design process is double checked by the QC and the design also represents the requirements. Without the check-out of the QC, there will be no design.

The QC takes the requirements and will design it’s own system within the design and such system contains its own phases of design, implementation and acceptance) , which will guarantee that project will deliver that on what is agreed upon in the requirements.

The design

The design is the phase, which will see several products being produced.

1. The Functional Specifications
2. The Technical Specifications

Those are the two main products or documents, which will produce the design. In practice, you have also documents like Data Flow and Data Design, Software Architecture, GUI specifications, Program Flow Specifications, etc. Those extra documents depends on the scope of the project, the complexity, the customer, the senior management and many other factors.

The Functional Specifications

Originally, this document is the translation of the main requirements document, except differently written (for the customer and/or senior management) and the project members. This is the document, which talks about the actual design and the actual product before it is actually build or developed. In this document are sections, which describes the databases, the system configuration, the program flow, how the product will look like and many other aspects of the project process towards the customer, senior management and the development organization within the project.

The Technical Specifications

This document is again an the translation of another document, in this case the Functional Specifications.

I prefer to … no … wait, I require that the technical specifications are being defined to the tiniest detail, because the technical specifications contains part of each button and its properties, which points to the database with the estimates, which enables me to use the estimates for the Scheduling.

In this stage we have also all the actual data for the creation of databases and/or stores until the level of the field and its relations between fields (imploding relations) and tables (exploding relations) and even databases (enterprise relations).

The database design in this case, must be ‘proven’ with data designs. With other words, the designer needs to proof to the design in general, why he or she needs that field and how it is used in the overall picture and what is the relationship of the field within the table and the database.

The program design is – as I mentioned before – a detailed description of each program function (i.e. each button, each label and each window must be documented (technically).

The relationship between the different items in the technical design is only here by break-down functionality, not chronological order of development. The Technical Specifications is a product by itself and it doe snot mean automatically that the project manager and designers will be involved with the implementation of the product, described in the technical specifications.

The Plan

In this stage, we know what the customer or senior management want, according the requirements. We know how he or she will visualizes the product (design), we also know how that will be implemented, and now it is time to make the plan (‘when is it ready?‘)

The Schedule

With the help of the technical specifications and the database with durations for each task, the resources available for the project, the location and space the project has available, only then we can make the schedule.

And for your information, no, I don’t use Microsoft Project in this stage. That’s poison! I create the schedule manually. In this stage, the chronological order of the tasks are important, because now I have the availability of resources and I know the “functional pecking-order” (from the technical specs as the requirements).

I usually start the schedule with the milestones (tasks without duration) and within those milestones I start to fill in the tasks, assigning resources is a task I do after the “functional pecking-order“. Durations will be imported from the estimates database and then I start to calculate the possible critical paths. That is the basis of fine-tuning the schedule and then the most fun start, namely telling the people in the project what their schedules are.

I need to tell you that many times I cheat in the scheduling. What I do is in the Functional and Technical Specifications I get myself a graphical designer (if I didn’t do that already) and he and a GUI programmer will make the screens. That is in practice the most of the work. If those specs survive the QC, those separate documents and projects are being used to speed up the scheduling time, because I mainly need developers for coding (instead of developers only coders, which is cheaper and faster.