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:
- Design
- Scheduling
- Implementation
(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.
- Requirements
- Functional specifications
- Technical specifications
- 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.
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 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.
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.
I'm not going discuss the variations and types of organization structures like the pyramids or slat-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.
Who or what is a Project Manager?
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 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.
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 slat-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.
The Project management blocks
First of all, project management (globally) is divided into several parts:
- Design
- Scheduling
- 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.
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.
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.
Functional specifications
After the acceptance test for the requirements, the functional specification phase has finally arrived. According the definition, its:
... is a formal document used to describe in detail for software developers a product's intended capabilities, appearance, and interactions with users ...
That's all true, but I want to state it a bit differently. The functional specifications is derived from the requirements, which details capabilities, appearance, abilities in the form of media (films, presentations, documents, etc.), and every aspect is referred to the requirements. The requirements is also changed, because each aspect the functional specifications discusses, is referred to parts in the requirements.
The functional specifications will formalize the requirements, present it in plain language with chapters, sub-chapters, paragraphs, etc. in a logical order with table of contents, index-tables, tables of figures, attachments, etc.
The functional specifications is filled with plain text, schemes, diagrams, flows, tables, studies, etc. Each detail is referred to the similar section into the requirements. If there is a section in each document not referred to each other, you will have a problem and your project fails.
In this phase, your project team will move to the premises of the project manager (the company where you work for usually). It's a very good idea to have a person in your project team, which is part of the customers organization, preferable a knowledgeable person. Expectations and expectations, one of the few aspects in project management you can't control.
The classical mistake for functional specifications is that such document is full with text, which actually says nothing, written like a company political document. This is wrong. If that happens, the project fails. As project manager you need to guard yourself and your project against such practices. If you detect that, the best way is to fire the writer(s).
Sizes don't matter. If your functional specifications are only four pages long, or thousand pages, it doesn't matter.
You also need to take into consideration that the functional specifications is the basis for the next phase, the technical specifications. Also you need to take care that every paragraph and sections in the functional specifications must have actual references to the requirements. In the requirements, each aspects must be referred to the functional specifications. If one or both documents doesn't have that, you project will fail. If the references are not complete or there are gaps, your project will fail.
Requirements are written up and presented in its various forms and they don't need to be ordered in a specific way, such media can give the impression of chaos and unorganized. The functional specifications are really presentable and written professionally and ordered accordingly.
The role of the QC manager in the functional specifications is important. The main thing what the QC manager is doing in this phase is producing acceptance tests, based on the requirements and the ready parts of the functional specifications. Because in the functional specifications, the GUI design is already designed and specified, as are the data models, process flows, program flows, it's for the QC manager relative simple (it's an administrative or engineering process) thing. In some projects, his or her work is included in the functional specs, or the QC manager is making his or her own series of documents.
And not to forget, all the acceptance tests and relevant QC-documents are referred to and from the requirements and functional specifications. There is in this way no risk that someone forgets something.
The QC documentation is actually very important for the legal aspects of your project. The QC is important for your project and without it, your project is likely to fail.
And just like the requirements, at the end of the functional specifications process, you have undergo an acceptance test.
Finally, before the acceptance test will take place for the functional specifications, you are officially forbidden to mention the technology you expect to use to build the product(s). In this phase, everything can go, even pen and paper instead of fancy computer systems.
Technical specifications
In scope of this document, you might define the technical specifications as the document(s) derived from the functional specifications (and the requirements).
Again, just like the previous phases, every aspect of the technical specification is referred to the functional specifications and the requirements. The same for the others, each document has references to all the phase documents in the design. That's very important and when you don't do something like that, your project will fail.
The technical specifications is the set of documents, which translates the functional specifications into terms of technologies with detailed designs (i.e. data-flows with lists of tables and fields and relations, etc). In this phase you are going to mention the technologies you are going to use, based on all the specs in the design has indicated, including the requirements. Be aware, you need to proof in phase what technology is better and proper and why.
There were projects, where the project people automatically choose the "open source" direction and everything went automatically into Linux and its 'free databases' without actually proving the point that such technical architecture could do its work, which is described in the requirements and functional specifications.
To chose technology or technologies for your projects is not an easy task. It's many times bound on the fact that you or the project manager works for a certain technology company, which is only developing or working with certain technologies. Also it's the fact that when using technologies, the project manager is not investigating the alternatives. Be aware, that at the end of the process, you have the fight for your budget. Using certain technologies might mean millions for your project.
For example, many people assuming that using Microsoft development platforms is much more expensive then the Linux equivalent. That's not true, the Microsoft development platforms are much cheaper then a Linux platform when you make enterprise applications.
For the perspective of the project manager (and he or she better do it otherwise there might be trouble), the person needs to proof that the chosen or available technologies is right for the project. And it's not only for the technical implementation, but also the availability of the knowledgeable people to hire to do the work. And there is another aspect involved. There were projects in the past, which were based on interesting technologies, but those companies representing and selling those technologies went down. Examples were for example Delphy and their fantastic Pascal, dBase from Ashtontate, FireFox, etc.
Other samples of technologies, like database technologies are more fuzzy, like the Oracle and MS SQL server database products. Both are able to do a great job, and both have capabilities, which are similar, with some small technical issues of both sides. But in those cases, a look at their price lists will make your choice very easy.
Talking about databases. Many people make a easy choice and chose for the free databases all available in all the major development and OS platforms. This is great, but for enterprise applications, this is killing and a for sure way to kill your own project. When you make a choice, make it based on actual facts and needs, which must be suitable for the requirements of the project.
In this phase, you need to take into consideration that the next phase, the collection of tasks are directly derived from the technical specifications. If you make a mess here in this stage, you make a mess in the task list and that means failure of your project. You can't have that.
The technical specifications might not follow the same or similar buildup of the functional specification chapters and paragraphs and it might spend loads attention into the translation of certain specifications into technical specifications.
What is also part of the technical specifications is the system design. Such design is the overall design about the hardware you are doing to use and if needed or required, which part of the specs are running on what platform and on what servers or stations or in any medium, using specific or industrial standards in communications, etc.
Also a very important fact is the security, which is handled here in this section or process in details.
In every technical specifications, there is a network diagram, even when the application or the product is only working on one computer without servers or network or Internet. In that diagram, you define the minimum (and maximum) system capacities, which is important later for the legal perspective (in case the customer is using other hardware with different capabilities).
The QC is also involved in this process, because whatever the process is deciding what it does or defines, it needs to be tested and see if it's ready for development and/or delivery and/or acceptance tests (in the future).
Don't forget, we have an acceptance test for the technical specifications. No alcohol.
So what are you going to do, you chop the problems in small parts and you start with the beginning. It's clear and simple. You go over all your specs, from the requirements to the functional and technical specifications and all sub-media and docs and start defining task lists, organized per section.
The next phase is that you create subtasks for each task (which needs something like that). For example, the login screen. It's a task and you create subtasks, which describes all the details, like two labels, two text boxes, two buttons and the logic behind everything, including restrictions (i.e. max. number of text). The tasks are displayed indented.
During this process, a good administrator will use pen and paper to do tat. Another way is to use software like Microsoft Project or TimeLine and other software packages like that. The purpose is to use that software for the presentation and automatic calculation of the tasks in duration, resources, budget, calendars, etc. In this software you can easily make changes and add or remove things without the need to print everything out and/or to redo everything again for the 1,000th time..
Again, in this phase it's not interesting how long something takes, or how much it costs, etc. It's a plain, but (indented) advanced task list. Each task has a number and that number is the reference from all design documentation pointing to the tasks and opposite. In each task, there are references added (in the description or notes of the task) to which parts of the requirements, functional specifications and|or technical specs.
Also this is the stage, which most project managers don't understand and hard to define. Be aware, also for this major stage you need to proof your work. So, if you think that it takes 4 working days to do a specific thing, like the login screens to make and tested, think again.
In Holland, there is an expression which says "Wet finger work". You lick your finger and stick it in the air and you might predict rain today or predict the duration of a certain complicated task. In project management, this is a killer. Your project fails and stops right there.
If you think to ask a programmer or whoever for the right duration, it's like using their wet finger to predict your doomsday. That does not work as well. I'm talking about the task duration.
Then there is the factor of resources. When people think about resources, they think about the development people, or the persons who must work on the tasks. And the 'holy' project managers are assigning the resources to the tasks without taking in consideration the sickness, holidays, free days, working times, pregnancies, events, birthdays, etc. It's the strait road to hell or failure.
Other samples of technologies, like database technologies are more fuzzy, like the Oracle and MS SQL server database products. Both are able to do a great job, and both have capabilities, which are similar, with some small technical issues of both sides. But in those cases, a look at their price lists will make your choice very easy.
Talking about databases. Many people make a easy choice and chose for the free databases all available in all the major development and OS platforms. This is great, but for enterprise applications, this is killing and a for sure way to kill your own project. When you make a choice, make it based on actual facts and needs, which must be suitable for the requirements of the project.
In this phase, you need to take into consideration that the next phase, the collection of tasks are directly derived from the technical specifications. If you make a mess here in this stage, you make a mess in the task list and that means failure of your project. You can't have that.
The technical specifications might not follow the same or similar buildup of the functional specification chapters and paragraphs and it might spend loads attention into the translation of certain specifications into technical specifications.
What is also part of the technical specifications is the system design. Such design is the overall design about the hardware you are doing to use and if needed or required, which part of the specs are running on what platform and on what servers or stations or in any medium, using specific or industrial standards in communications, etc.
Also a very important fact is the security, which is handled here in this section or process in details.
In every technical specifications, there is a network diagram, even when the application or the product is only working on one computer without servers or network or Internet. In that diagram, you define the minimum (and maximum) system capacities, which is important later for the legal perspective (in case the customer is using other hardware with different capabilities).
The QC is also involved in this process, because whatever the process is deciding what it does or defines, it needs to be tested and see if it's ready for development and/or delivery and/or acceptance tests (in the future).
Don't forget, we have an acceptance test for the technical specifications. No alcohol.
Task lists
Tasks lists is as the name already indicates, a list of tasks. Also this stage can easily moved towards the next phase, the scheduling and it's true. The scheduling is derived from the task list.What's the task list in the perspective of the design?
As usually, you build the task lists from the specifications. Each task list is nothing else then a list of work, which needs to be performed. In this stage, you don't care about the time, dates, order, or what task must be done before or after or during the others, who is doing what, how long it takes and where it can be performed, etc. To do all of those things means that it's a very complicated process and with each complicated process, you make mistakes and you are in trouble and your project fails.So what are you going to do, you chop the problems in small parts and you start with the beginning. It's clear and simple. You go over all your specs, from the requirements to the functional and technical specifications and all sub-media and docs and start defining task lists, organized per section.
The next phase is that you create subtasks for each task (which needs something like that). For example, the login screen. It's a task and you create subtasks, which describes all the details, like two labels, two text boxes, two buttons and the logic behind everything, including restrictions (i.e. max. number of text). The tasks are displayed indented.
During this process, a good administrator will use pen and paper to do tat. Another way is to use software like Microsoft Project or TimeLine and other software packages like that. The purpose is to use that software for the presentation and automatic calculation of the tasks in duration, resources, budget, calendars, etc. In this software you can easily make changes and add or remove things without the need to print everything out and/or to redo everything again for the 1,000th time..
Again, in this phase it's not interesting how long something takes, or how much it costs, etc. It's a plain, but (indented) advanced task list. Each task has a number and that number is the reference from all design documentation pointing to the tasks and opposite. In each task, there are references added (in the description or notes of the task) to which parts of the requirements, functional specifications and|or technical specs.
Schedule
Easy here. You need the task list, which is described in the previous section.
Pitfalls of the scheduling
This is the moment most projects will go to hell or haywire or down the drain, except that most project managers don't know it yet. How would you feel that you did something, which causes your death while you don't realize it until it's too late (like they bury you or they kick you out or you cause many people to lose their jobs and cause millions of dollars of damage to the customer, your company and yourself)!Also this is the stage, which most project managers don't understand and hard to define. Be aware, also for this major stage you need to proof your work. So, if you think that it takes 4 working days to do a specific thing, like the login screens to make and tested, think again.
In Holland, there is an expression which says "Wet finger work". You lick your finger and stick it in the air and you might predict rain today or predict the duration of a certain complicated task. In project management, this is a killer. Your project fails and stops right there.
If you think to ask a programmer or whoever for the right duration, it's like using their wet finger to predict your doomsday. That does not work as well. I'm talking about the task duration.
Then there is the factor of resources. When people think about resources, they think about the development people, or the persons who must work on the tasks. And the 'holy' project managers are assigning the resources to the tasks without taking in consideration the sickness, holidays, free days, working times, pregnancies, events, birthdays, etc. It's the strait road to hell or failure.
To do the right job in scheduling
First you need to have the complete task list (which contains (hopefully) the subtasks). If you look to the task, it has several important properties, which you need to define.- Title of the task, as you see fit or is proper
- Description of the task, where you need to summarize the work, based on the specs. In the description you have all the detailed reference numbers to all specifications.
- Start and end dates you can forget. Not interesting. More about this later.
- Duration. Yes, this is important, but you don't fill in the duration, but it's the product of an advanced lookup from the so called programmers library. More about this later.
- The connectors or relationships with other tasks. For example, this tasks starts when one or more tasks (finally) ends or finishes, or the connection can be that this task only starts, when a number of other tasks starts too, etc.
- The connectors have the common code like S (start) and F (finish). It will look like this: FS (it's finished, then you start), or FF (when he finishes, you need to finish too), SF (start finish), etc.
- The connectors or relationships between the tasks has a property with the name Lag-time, which is nothing else then a duration between two tasks related with each other. For example, task 665 starts when task 674 and 12 finishes and must wait for x-days or hours because of the lag-time of the connection. Many PM are using the lag-time as reserves, but sometimes they really need that because of work pressure, or the paint is not dry yet, etc.
Begin and end date and times
You don't fill those in. The begin dates and times of tasks are automatically calculated based on the relationships (the connectors) between tasks and the duration. If someone is adding holidays or work hours to the system or change them, the start dates of the task will change dramatically.
Many project managers are 'hard coding' the start date of a task, and this will cause project and task conflicts and terrible delays. If you know such project manager, fire him or her on the spot.
Many project managers are 'hard coding' the start date of a task, and this will cause project and task conflicts and terrible delays. If you know such project manager, fire him or her on the spot.
Task duration
As a project manager, you never define the duration of a task, based on a person or resource. There is an extremely valuable resource for the those who making scheduling and in the IT (software IT) I call it the programmers library. It's an advanced book or list, where all possible software tasks in all its variants are registered with the average durations in time to make or develop that functionality. Not only that, there is also an entry of the number of programing lines needed or required to make something working like that. The last one is important for the prediction or calculation of the expected defects.
So back to the sample of the login screens, such thing has several subtasks:
- Create the window
- Set the visual properties like background color, font sizes, etc.
- Add a label with a certain text
- Add the text box with certain limits (i.e user name)
- Etc.
For each task there is a duration mentioned in the programming library and you use that value in the duration field of the task. Take care that you also take the value of the number of expected lines of code, which might differ depending on the programming language being used. In Assembly you might need less code then in old in old Pascal, C++, C# or anything else.
Resources
I always use the term resource management and no, it's not something connected to your programmers (only). Resources in project management means the pen or pencil, the chair, table, computer, mouse, monitor, (external) equipment and software, shoes, clothes, coffee-cups, coffee, tea, beer, sugar, milk, room, building, etc. Everything. Why? Because everything cost money. And because we are going to calculate the money the project costs, you need to include everything, from the building, the rooms, even the tea cups, e-v-e-r-y-t-h-i-n-g.
But we are not finished here. For example programmer X needs a laptop. For the sake of your mental health, take care that the laptop is 'clean' and has no problems, has security software, all the proper versions of the software you need and the network connections and he or she has a valid account in your email and/or web server and whatever.
And that brings us to the next issue about resources, especially the human resources and that's the people you need in order to maintain and support your project. For example, you need a network manager if your team is big enough. "Borrowing" a network manager from your company is not a good idea, because you can't schedule him or her and such person falls outside your authorization (do what I tell you type of authorization). If you fail here, your project will fail.
Each resource, human or not, has a personal calendar, which is or will be adapted to your project. Here vacation days can be added, the working hours, maintenance time, etc. When you're going to assign the resources to the tasks, this has a direct impact on the total project. And that's the human resources, but think about the building and/or rooms. In certain situations, you need to hire rooms and this will be relevant. You can't assume something, you need to check the availability of the room or space and you need to double check the resource (maybe there is no network, or WiFi, or no bathroom or no running water or no electricity, etc. If you don't do that, you might run into nasty surprise during the project and it might be failing your project.
When you do your resource management, you might very likely add additional tasks to your project. Most of those tasks will be organized under one parent task, which I normally call pre-project (and sometimes post-project).
For example, for programmer X, he needs two mobile phones and a laptop with three different operating systems to do his or her work. The tasks for those devices must be performed by the network admin and that cost time.
Also, each resource cost money, whatever it is. If we are talking about the human resource or the coffee cup, all of it cost money. For the computers they need valid software, like maybe Office, anti-virus software, development environment, and the servers needs to be configured with all the valid software and that all cost loads of money.
To make the mistake by working on an existing network or computers or building and rooms is dangerous and very likely to happen and you endanger your project doing that. If that's the case, you need to check everything before you can determine what work you must perform before you can start working on your actual project. And with checking if everything is alright, don't you ever rely on the local workers of the network and computer equipment; let an external check it out and you'll be amazed (or horrified). Failure to do so ends your project in disaster.
Shortly, part of risk management is reducing the risks.
For example, the GUI is finished, the databases are created and tested, an important part of the program or project is finished, or the stage of (sub-)payment is reached.
Mostly, those milestones are combined with acceptance tests, where the QC performs live the final tests about the already development part of the project. If those tests succeeds, that part is working and accepted. In many cases payments follows. In those tests, customer is involved by inviting the involved people from the customer and their (senior) managers.
Shortly, part of risk management is reducing the risks.
Milestones and acceptance tests
A milestone is a task without duration. A milestone is being used to indicate that a certain stage has reached within the project time line.For example, the GUI is finished, the databases are created and tested, an important part of the program or project is finished, or the stage of (sub-)payment is reached.
Mostly, those milestones are combined with acceptance tests, where the QC performs live the final tests about the already development part of the project. If those tests succeeds, that part is working and accepted. In many cases payments follows. In those tests, customer is involved by inviting the involved people from the customer and their (senior) managers.
Finally connecting the dots in scheduling
So far great. You have the task list, you organize the sub-tasks, so you cover as much as details as possible as sub-tasks (or sub-sub-sub-sub etc. tasks).
The next step is connect the tasks (FS, SS, FF, etc.).
Then you define the durations from the programing library
Add the pre-project and post project tasks to your task collection and take care that those tasks are properly connected to your task collection.
Then you change the start date of the project and watch the fun. Start the project on a Monday and watch the duration and the end date. Change the start date with one day earlier or later and watch the fun. You will be surprised.
Define the project calendar. In this calendar, you define the working days for everyone, and the holidays and free days, etc. The duration immediately changes.
As I wrote before, you don't add or define any start date ... except the date when you want to start.
This is the time to discuss the personal calendars with the people you are going to work with. If you are going to hire them, ask them for their plans when they and you are in project.
This is the time to discuss the personal calendars with the people you are going to work with. If you are going to hire them, ask them for their plans when they and you are in project.
Until now, you didn't assign the resources, because that's truly a pain in the backside.
An example. You assign three programmers to 20 tasks and then you see how that works out in work continuity. You might (very likely) observe that one programmer works 20% of the time, the other 80% of the available time and the third another percentage. You and that everyone works 100%, not 99% of the available time. Reason? Programmer 2 is assigned to the beginning tasks, while programmer 2 and 3 are waiting until he finishes (that's the way of the connection between the tasks). This is one of the reasons of something like that happens. Or one of the programmers has a holiday or one programmer has a longer weekend then the other, etc.
I personally use another method. I visually display everything on the walls (or huge white boards) and move my resources in a way, that everyone is as productive as possible. You can feel like a general planning for battle, because you're surrounded with large pieces of paper nailed to the walls.
Sorry, for me it works.
Other project managers using another method to do this type of complicated work. They use large tables and little cards with the name of the resources and color coding. Computer cards are green, people are red, etc.
Sorry, for me it works.
Other project managers using another method to do this type of complicated work. They use large tables and little cards with the name of the resources and color coding. Computer cards are green, people are red, etc.
And be aware, that each task doesn't have the human resource assigned, also his or hers computers, additional equipment, work space, additional software, etc. And don't forget the coffee, the breaks, the meals, the snacks, the parties, the water or drinks, etc. Anything which cost money must be scheduled.
But as usual, you are not finished here. You have the schedule almost ready and almost all the needed points added to the linked or connected tasks and resources are assigned to the tasks. You will notice that the duration and project end date are changed dramatically!
You have also other views, and the view of the tasks or schedule based on costs. Those numbers are calculated with the rates you defined in the resources, which includes everything. This number or numbers can be used for the budget calculations.
Each task is linked too to all the aspects and details in all the design documents and media, like requirements, functional specifications and the technical specifications (and opposite). For example, in the requirements you can see any requirement is handled in the following lists of tasks.
Development units
To make things interesting for the project manager, you might (re-)consider something what I call development units. It's a method Microsoft like to use for their projects.
Instead of a conventional individual resource (a person), you define small development team working on a certain task. For example team X:
- Senior developer
- Junior developer
- Software tester
- Database person (DBA)
- Graphical designer
In the above example the development team for a certain number of tasks contains out of five people with their own specialization.
- The senior developer is mostly the tea leader of the team
- And the junior developer is doing the work
- The software tester is a great idea, because he will be the one who are actually tests the task and defines if it works or not, according the specs. Any defect or big discovered in this stage is fixed on the spot.
- The database person or the real DBA is there for the SQL script, which needs to be developed and/or tested.
- The graphical designer is designing the user interface or the GUI.
Such team is extensive and might be used if you use two or three development units, but it does its job, better then using a single developer for the task. Such task with such resources must be scheduled sequentially with the work for database, testing, graphical design and it must be integrated with each other when its finished.
We start with the name. Especially in Israel, where QC is so undervalued and misused, they mix-up the QC and QA. QC stands for Quality Control and QA stands for Quality Assurance. QA applies to the quality of work company-wide and QC applies to projects.
The work of the QC manager is actually managing his team of QC people and of course writing part of the specifications, but focused on checking out the functionality and existence of anything mentioned in the requirements. In an IT project, the only way to do that is building a detailed database with all the test plans, his or her people need to use in order to proof that the functionality is developed according the specifications.
The default work for the QC manager applies here, like defect or bug management and the defect life cycle (discovery, reporting, classifying, prioritizing, fixing, re-check).
Another important task of the QC manager is the prediction of the number of defects. He or she can indeed predict the number of defects in any given IT project, before it's programmed or developed. If, at any chance, there are more or less defects discovered, the project manager will be very upset, because something is going on and the PM doesn't know it (yet). He will immediately start to investigate. The factor (good or bad) luck does not exist for the project manager.
How can you predict the number of defects in a program?
By assigning a quality number to the programmer or developer. For example, he or she makes an average of 10 defects in 1,000 lines of code or an average of 23 defects in 47 hours of work.
The project manager will know the quality of the QC team(s), the QC knows them too. They can use that information to calculate the quality of the project at any given time of the project-life.
For example if the QC reports 100 defects, the project manage knows that they covered only 80% of all the real defects.
A project manager can cheat of course. And I love cheating. So I take care that there is always a software tester with his or her test plan working together with the programmer. The programmer will never decide when he or she's finished with a certain task, but the software tester does.
If it's true or not, knowing the test score of the software tester (his score is for example 80% discovering all defects), the PM and QC manager knows that there are 20% bugs hidden in the code or product. The code is 10,000 lines long and statistically will have 100 defects (quality of the programmer), there are 20 defects not discovered!
The QC (Quality Control)
The last, but not the least. Through project management history, the QC had different and changing roles.We start with the name. Especially in Israel, where QC is so undervalued and misused, they mix-up the QC and QA. QC stands for Quality Control and QA stands for Quality Assurance. QA applies to the quality of work company-wide and QC applies to projects.
The work of the QC manager is actually managing his team of QC people and of course writing part of the specifications, but focused on checking out the functionality and existence of anything mentioned in the requirements. In an IT project, the only way to do that is building a detailed database with all the test plans, his or her people need to use in order to proof that the functionality is developed according the specifications.
The default work for the QC manager applies here, like defect or bug management and the defect life cycle (discovery, reporting, classifying, prioritizing, fixing, re-check).
Another important task of the QC manager is the prediction of the number of defects. He or she can indeed predict the number of defects in any given IT project, before it's programmed or developed. If, at any chance, there are more or less defects discovered, the project manager will be very upset, because something is going on and the PM doesn't know it (yet). He will immediately start to investigate. The factor (good or bad) luck does not exist for the project manager.
How can you predict the number of defects in a program?
By assigning a quality number to the programmer or developer. For example, he or she makes an average of 10 defects in 1,000 lines of code or an average of 23 defects in 47 hours of work.
- That's the reason why I want to know - during filling in the durations of tasks - the number of programming lines or lines of code for each functionality.
- If I don't know the quality number of programmers, I add in the schedule the tests in order to get those numbers. I specify bogus software with loads of lines of code and let the programmers program them, and very carefully tested.
- If I want to know if the QC team is good enough for that, I do the same with them. A good programmer is making a program, and will add 50 defects on purpose into the program and see how many defects will be detected and/or reported.
The project manager will know the quality of the QC team(s), the QC knows them too. They can use that information to calculate the quality of the project at any given time of the project-life.
For example if the QC reports 100 defects, the project manage knows that they covered only 80% of all the real defects.
A project manager can cheat of course. And I love cheating. So I take care that there is always a software tester with his or her test plan working together with the programmer. The programmer will never decide when he or she's finished with a certain task, but the software tester does.
If it's true or not, knowing the test score of the software tester (his score is for example 80% discovering all defects), the PM and QC manager knows that there are 20% bugs hidden in the code or product. The code is 10,000 lines long and statistically will have 100 defects (quality of the programmer), there are 20 defects not discovered!
No comments:
Post a Comment