1 Building Software: How to run successful projectsSoftware Engineering Building Software: How to run successful projects
2 Introduction The “software crisis” of the 1960s and 1970s was so called because of a string of high profile software project failures: over budget, overdue, etc. The crisis arose in part because the greater power available in computers meant that larger software projects were tackled with techniques developed on much smaller projects. Techniques were needed for software project management. Good project management cannot guarantee success, but poor management on significant projects always leads to failure.
3 Kano model for quality requirementsThis is a model of the relationship between customer satisfaction and quality requirements. If the requirements are incomplete, software practitioners end up building a software product that does not meet all of the customer and user’s needs. Expected quality The expected quality line represents those quality requirements that the customer explicitly states. Example: They will state their preferences for the make, model, options, and gas mileage when shopping for a car. The customer will be dissatisfied if their explicit requirements are not met. As a result, he/she will go to buy a car somewhere else. The customer’s satisfaction increases as more of their explicit requirements are met. When enough of their explicit requirements are met, the customer shifts from being dissatisfied with the product to being a satisfied customer. Basic quality There is a basic level of quality requirements that a customer expects the product to have. These are requirements that are assumed by the customer and are typically not explicitly stated. Example: They expect a car to have four tires, a working engine, and a steering wheel. The basic level of requirements does not satisfy the customer. The entire basic line is in the dissatisfaction region. Absence of this level of quality requirements will increase a customer’s dissatisfaction. Exciting quality It is the innovative requirements level and represents unexpected items. These are items that customers do not even know they want, but they love them when they see them. Example: The cup holders in cars Today’s innovations are tomorrow’s expectations. The entire excited quality line is in the satisfied region. The expected quality requirements are the ones practitioners can elicit fairly easily if they talk to the product’s stakeholders. 3
4 Software projects Software projects have several properties that make them very different to other kinds of engineering project. The product is intangible. Its hard to claim a bridge is 90% complete if there is not 90% of the bridge there. It is easy to claim that a software project is 90% complete, even if there are no visible outcomes. We don’t have much experience. Software engineering is a new discipline, and so many developers simply don’t have much understanding of how to engineer large scale software projects.
5 Software projects Software projects have several properties that make them very different to other kinds of engineering project. Large software projects are often “bespoke”. Most large software systems are one-off, with experience gained in one project being of little help in another. The technology changes very quickly. Most large software projects employ new technology - for many projects, this is the raison for existence.
6 Software Projects The effective software project management focuses on four P's. The People The Product The Process The Project The Project In order to manage a successful software project, we must understand what can go wrong (so that problems can be avoided) and how to do it right. A project is a series of steps where we need to make accurate decision so as to make a successful project.
7 Software Projects The ProductBefore a software project is planned, the product objectives and scope should be established, technical and management constraints should be identified. Without this information it is impossible to define a reasonable cost, amount of risk involved, the project schedule etc. A software project scope must be unambiguous and understandable at the management and technical levels. To develop a reasonable project plan we have to functionally decompose the problem to be solved.
8 Abstract product model (V-model)
9 Software Projects The ProcessHere the important thing is to select an appropriate process model to develop the software. Processes & Entropy Processes are built to bring order to chaos. If projects are failing in one’s own organization, look at the processes at work There are different process models available. They are waterfall model, Iterative waterfall model, prototyping model, evolutionary model, RAD(Rapid Application Development) model, spiral model. In practice we may use any one of the above models or a combination of the above models. Processes are built to bring order to chaos. Situations will tend to migrate a system from an ideal stable state of equilibrium to a state of chaos. Project management processes are used to restore equilibrium states. If projects are failing in one’s own organization, look at the processes at work One may not have enough of them to begin with or not have the right ones for one’s requirements. All processes are planned expenditures of energy to restore the system to equilibrium. Processes for escalation, communication, development, project management, testing, material acquisition, accounting, and others.
10 Software Projects The PeopleThe following categories of people are involved in the software process. Senior Managers – they define the business issue. Project Managers – they plan, motivate, organize and control the practitioners who do the software work. Practitioners – they deliver the technical skills that are necessary to engineer a product or application Customers – they specifies the requirements for the software to be developed End users – they interact with the software once it is released.
11 People and processes Matching resource to need Correctness of processGood team, but wrong or bureaucratic process Good team, and right, tuned process Matching resource to need Mismatch in resources and bureaucratic processes Mismatch in resources, but following the right process Correctness of process 11
12 Insourcing vs. OutsourcingThe insourcing: It is the use of consultants and contractors who work along with employees to deliver on projects and assignments. Consulting also can be used strategically when a company wants to stick to its primary work and considers IT as too much distraction from its revenue-generation activities. Consulting companies can deliver the skills more easily from central pools. Organizations, and for that matter employees, often have a ‘Love/Hate’ relationship with consultants. Consultants sometimes are seen as gurus and lifesavers; At other times management sees consulting as merely cash going out the door. Employees may resent the higher rates given to consultants to do something “that they could have done equally well.” 12
13 Insourcing vs. OutsourcingThe insourcing: Some organizations have become overly dependent on consultants for their operations, with employees playing more of a coordination and management role. Such a dependency poses a strategic risk. Management should be evaluating that risk periodically. Management may make perfect sense not to have any of those skills in-house or it may not, but it must be evaluated and controlled by choice and not allowed to unknowingly develop into such a situation. Employees may resent the higher rates given to consultants to do something “that they could have done equally well.” 13
14 Insourcing vs. OutsourcingThe outsourcing: There is an increasing trend, in recent years, to outsource “offshore” the development and support work of the company. If the majority of the responsibility for delivery shifts to an outside party, then the work has been outsourced. It does not matter that the supervision is retained, because the customer must always maintain a certain amount of supervision and coordination. To do this is, obviously, a strategic decision for company management to take. 14
15 Insourcing vs. OutsourcingThe outsourcing: If development work is done offshore, then the technical knowledge and the business knowledge accumulate there. Going offshore is not always about outsourcing. Sometimes it is part of the normal growth of offices and facilities to newer geographical markets. The management and control systems in place in such situations may be merely local variations of the central corporate systems. The vendor works within the scope of a contract. This can make getting things more difficult or expensive than in a command structure. It is not easily reversible if the employees who were doing the work previously have been released. It is not easily reversible for other important reasons as we What might begin as a cost-saving measure could lead to a lock-in based on the contractor’s knowledge and experience. 15
16 Insourcing vs. OutsourcingThe outsourcing: When something is outsourced, there is a shift from a command structure to a contract structure. When resources are internal (employees or contractors) work gets done through a command structure: workers are part of a command hierarchy and know it. When work is outsourced, getting the same work done involves going through a contractual relationship between two businesses. Because a contractual structure replaces a command structure, is the reason that an outsourcing model may not be suitable for many kinds of projects and companies. 16
17 The axioms of success The Law of ‘Requisite variety’ (W.R. Ashby)“Only variety can destroy variety.” The practice “Gold Plating” It can take place when functionality is added to the software that was not in the requirements specification The Rule of 7P’s “Prior Proper Planning Prevents Piss Poor Performance” Procedure KISS “Keep It Simple, Stupid !” ‘‘Requisite variety’ Ashby’s law, in a way, simplifies the model because the regulation of variety focuses on “relative” parameters of complexity rather than “absolute” ones. Simply stated, it means that for any system to regulate (manage) another system or its environment, it must have at least as much variety (complexity) as the system it is trying to control. This law is one of the most general systemic cybernetic principles. It is useful in understanding any type of system. KISS A well-known software design guideline is captured by the acronym ‘KISS’ (“Keep It Simple, Stupid !”). Having a process that is explainable and understandable is key. It is better than having a complex process that covers all aspects but is not understood by anybody. A process that is too complex is destined for failure. One should not add any tasks or activities to the process unless they are critically needed. Instead of trying to define steps for every condition that could possibly arise, one could have a ‘catch-all’ step. Do a periodic sweep of the processes to remove any legacy tasks that have no current significance. Gold Plating The are two kinds: A first kind comes from developers: They believe “the user will just love” A second comes from users: They are asked “What they want ?” rather than “What they need to be able to do with the system?”
18 Structured Project ManagementThe 10 steps are the cornerstone of structured project management: Visualize the goal - set your eyes on the prize. Make a list of jobs to be done. There must be one leader. Assign people to jobs. Manage expectations, allow a margin for error, have a fallback position. Use an appropriate leadership style. Know what's going on. Tell people what's going on. Repeat Steps 1–8 until step 10. The Prize. Steps 1–5 do indeed produce a plan for your project. However, what they also do is to define one possible way in which the project might actually unfold Example: If you build into your project plan the level of intricate detail as a part of steps 2 and step 4, then your plan will reflect a possible way that the project could actually happen. The other five were to do with implementing the plan and achieving the goal. Steps 6 to 10 turn the plan into a self- fulfilling prophecy.
19 Structured Project ManagementThe key to all of problems with projects is the word ‘detail’ above. The conventional wisdom is that you can't know much about a project, particularly a software project, at the beginning. You can catch every fragment of detail that you can as early as possible. Only in this way can you build a possible scenario of how the project might turn out. Too much detail early in a project is ‘inefficient’. Plans were criticized for being ‘too detailed’. In reality, developers think about a single model but they actually produce multiple models. Steps 1–4 cause you to build a prediction of the way the project might turn out. First part of step 5 gets you to build some contingency, or margin for error into your model. This means that, to some extent, things can turn out differently from your prediction, and it still won't be a problem provided the differences are covered by your margin for error. First part of step 5 then allows for the fact that people – your boss, your customer – may not like what your prediction says. This again, is no problem. What you do then is to use your initial model to produce a whole series of models. For example, if they are not happy with the existing delivery date, you can say "OK, here's a model showing what we can do by the date you require," or "Here's what we can do if you give us extra people."
20 Structured Project ManagementHaving multiple models we want to do then is to make things actually happen in right way We need to make reality adhere to the plan, to turn the plan into a self- fulfilling prophecy (step 6 to 10) Making reality adhere to the plan does not require anything like the god-like levels of ability that such a statement might seem to imply – this is one of the most conceptually simple things imaginable. Thus you get two chances to make your project a success: First: by planning your project in intricate detail Second: by causing your plan to become a self-fulfilling prophecy.
21 Structured Project ManagementBrains first and then hard work. That's the basis for a way to carry out any project. Structured project management follows this approach in that half of its 10 steps are to do with planning the project, i.e. they occur before the project really gets moving. This reflects a firm : that most projects succeed or fail because of decisions made during this planning phase. The rule of 7 P’s
22 1st Step: Visualize the GoalThis step clearly identifies the goal. Raymond's now widely accepted hypothesis is that new free software programs are written, first and foremost, to solve a specific problem facing the developer. If you have an idea for a program in mind, chances are good that it targets a specific problem or "itch" you want to see scratched. This idea is the project. Articulate it clearly and write it out: describe the problem you will attack in detail. The success of your project in tackling a particular problem will be tied to your ability to identify that problem clearly early on. Raymond tells : “…every good work of software starts by scratching a developers itch."
23 Visualize the Goal The definition of the goal is crucially important.Visualizing the goal tightens the definition of the basic goal. What constitutes completion? If answer is so obvious, make a checklist of all the deliverables. To put it another way, write down all the state changes that must occur for the project to be considered complete. In visualizing the goal you start to imagine life as it will be when the project is completed. Mentally you have already made the journey from where you are to this new place. Inevitably, some of the issues that will confront you during this journey start to make themselves apparent.
24 Visualize the Goal Nobody is daft enough to believe that the goal, once set, will never and can never change. In the real world we expect that things will have been forgotten, overlooked, appear differently, change or become redundant as the project proceeds. We have no problem with this provided we have a mechanism for controlling these changes. Change control: Any change control mechanism we institute has to operate within the confines of the 1st Law of Project Management. It can be implemented very simply using a change control log. Each change page basically describes: the nature of the change; an analysis of the impact; what action was taken. Any change control mechanism we institute has to operate within the confines of the 1st Law of Project Management.
25 The 1st Law of Project ManagementIt states that on any product or system development project there is a function that relates four variables. Functionality (F) Delivery date (DD) Effort or cost (EC) Quality (Q) The law says that there is a function of these four variables that is constant, i.e. Function (F, DD, EC, Q) = Constant Example: Increase functionality, let's say by adding a new feature, and delivery date will extend or effort will increase or quality will go down, or some combination of these, for the function to remain true. It is the reason why nothing can be absorbed into the schedule. One of the immortal phrases from software projects is “We are absorbing that into the schedule”.
26 Visualize the Goal Two possible ways to visualize the goal are:Using a checklist which focuses, among other things, on the day the project will end; Using method based on thinking of the goal of project in terms of three mutually perpendicular axes (functionality, good/bad, time).
27 Visualization checklistThis technique is based on questionnaire: What will the goal of the project mean to all the people involved in the project when the project completes? What are the things the project will actually produce? Where will these things go? What will happen to them? Who will use them? How will they be affected by them? What will the completion of the project mean to the team as a whole and to each of its members? Why do they want to do this project? Why do you want to do it? What will life be like on the day/week the project completes? What will you do that day? During that week? What will be your routine? Your schedule? Where will you eat? Whom will you meet? What will be the topics of conversation with these people?
28 Visualization checklistThis technique is based on questionnaire: What will people be saying of the project and its deliverables? You? Your boss? The people who worked on the project? The customer for whom you carried the project out? What would you like an audit of the project to be reporting? How will you feel? What do you think people will be saying about you? Your boss? Peers? Subordinates? The project's customer? Other parts of the organization? What will be your ambitions/hopes/dreams on that day? Will your standard of living have changed? Will your position within the organization have changed? Will your view of yourself have changed? If so, how? Do you think it is a difficult task you have set yourself? Could it fail?
29 Visualization checklistThis technique is based on questionnaire: How would you feel then? What would you do? Will you have power you don't have at the moment? Will you have changed as a person? If so, how? What sort of recognition will you achieve for this project? What would you like to do after this project is over? What would the best possible outcome of this project be?
30 Functionality, Good/Bad, TimeThis is the second way to visualize the goal. Functionality Low on this axis means minimal functionality. Good / Bad What is the best possible outcome from your point of view? Time: how you define the end of the project is. What lies within the scope of the project and what lies outside it ? That you know what elements form part of your goal and what elements definitely don't.
31 The 2nd method The goal of your project is visualize as a point in 3D space based on the points you select on the three axes. Thinking about these three aspects of your project puts a boundary around the goal and determines what lies within and outside the compass of your project.
32 A list of the jobs to be doneMake a list of the jobs that need to be done and you've got yourself your project plan. The very first thing to do when you start a new project is to make a plan. The question is: “What if you don't know everything that has to be done?” You may only be able to write down the first one or two tasks, but you're already moving forward. Get yourself to that first horizon and then take stock of what needs to be done next. For the rest of the project it is enough that you have mapped out in broad terms the remaining milestones (horizons) along the way. Not a problem. You know where you want to end up and you know the general direction to take, but you have no idea what lies between here and there. All you can see is the first horizon: Only when you get there can you decide how to face the next bit of the journey. Get yourself to that first horizon and then take stock of what needs to be done next. You will always know in quite a lot of detail what lies between you and that first horizon, even though there will inevitably be surprises.
33 A list of the jobs to be doneAs soon as a project gives any sign at all of starting, we are in a position to make a list of jobs for it. The list should be detailed to the first milestone and give the major milestones thereafter. Add any other available detail to the remaining milestones. This isn't essential, but given that we may have such detail available, and that we will have to put it in some day, we may as well do it now. The advantage of this is that it starts to give us some feel for the magnitude of the remainder of the project.
34 A list of the jobs to be doneThere will come a time when you have to predict the remainder of the project In the computer industry these predictions are named SWAGs (scientific wild-ass guesses) You will never feel entirely happy about predictions when you are forced to make them. In some situations, you may be forced to make predictions and know that in the first case, maybe your job is on the line, and in the second, lives are on the line. No doubt about it: a lot of projects are about serious things, and a lot of project leaders make decisions which do affect careers and/or lives. Try to postpone that moment for as long as possible, until you have gathered as much information as you can upon which to base your decision. You can start to get a feel for how accurate your guessing is and adjust your plan accordingly.
35 A list of the jobs to be doneThe list can be in any form - many large companies have a defined standard and layout for a project plan, and you may have to follow this. Write down the jobs that you know have to be done to get the project started and leave the crystal ball-gazing until you feel yourself better informed. Jobs must be explicit. Think through or write down the sequence of events that must happen for the job to be carried out. When drawing up your list of jobs, the following may help to ensure you have covered all possible jobs and areas. It can be an actual list, like a shopping list. It can be put on to a computerized project planning package. It can be a chart. If you cannot do this, or if you fudge it, then the chances are you're not being explicit enough. Often this is because what you are treating as one job is in fact a series of jobs. What you should do is to break it down further. It doesn't matter a toss what it looks like. It doesn't matter that you don't yet know all the jobs that need to be done.
36 A list of the jobs to be doneAssuming you have drawn up your basic list, check the following. Resources (equipment, products, services, facilities) required. Skills required and whether these imply hiring and/or training. That you have listed explicit, clearly identifiable milestones. Timescales, costs and budgets – show how you arrived at your estimates. That you have explicitly stated what assumptions you are making. That you have explicitly stated what dependencies there are on things which are not directly under your control. That you show explicitly who is responsible for what. That you have given some thought to what the really high-risk areas are.
37 The Leader The project must have one leader. There must be one leader.It can't have no leaders. It can't have two leaders or a committee of leaders. Unhappily, the converse isn't true: having a leader doesn't guarantee success There must be one leader. This is not the person with the title, but a person who is going to get the project done. She/he lives, eats and breathes the project. She/he is going to get it done or die in the attempt. At any given time she/he has her finger on the pulse of the project and knows how it's proceeding. Her name is so intimately bound up with the project that when you think of one you think of the other.
38 The Leader A fairly negative way of looking at project leader is that she/he is the person whose ass is pinned to the project and who will get fired if it doesn't work out. In the terminology she/he is the project champion. One thing that can happen to project leader is that her/his leadership can be subject to challenge by another member of the team. This means that somebody else tries to take over the psychological leadership of the project. If you don't neutralize the challenge, she/he will end up with multiple leaders on your project.
39 The Leader One idea developers have come across a few times in software projects is that of having a technical leader and a managerial or administrative leader. The managerial leader is more a manager-type person who has no interest in technical issues, while the technical leader doesn't want to be a manager, but still wants to have a big say in what goes on. Forget it: there must be one leader.
40 The Leader: Example Example:A large project involving a consortium of three companies: the prime contractor (P) and two subcontractors(S1 and S2). There are three logical units in the project: development installation support Within each of these units, each of the contractors will have certain roles to play. Contractor P might be responsible for physical installation of the system. S1 might be responsible for data take-on. S2 responsible for education.
41 The Leader: Example A proposed organization chart
42 The Leader: Example A proposed organization chartThe project as a whole has a leader – the box marked program manager. Each unit also has a leader, the project leaders. What are the project managers doing? Nothing – because the project leaders are doing it? Duplicating what the project leaders are doing? Clearly, there are two ways to settle this. Either have three people, one responsible for each of the logical units, or have three people, one responsible for each contractor's contribution. All the way down the tree, a single person must be identified whose ass is on the line for each particular part of the project.
43 The Leader: Example Thus, at the next level down, there would be a person responsible for each of the components such as installation, data take-on, education, etc. Be careful of organization charts. They can give the illusion that there is a single leader at each level in the hierarchy. However, look behind them, look at the one for your own organization. See if the one leader principle applies – if there really is a person whose ass is on the line for each part of the project that makes up your organization.
44 Assign people to jobs Many of the projects we encounter are too big for one person, and are carried out through using other people. The overall goal of the project can be thought of as a picture broken down into pieces like a puzzle. There are three things you need to do as part of this step: Make sure each job has a name against it Take people's other commitments into account Try to maximize the strengths of the team you've got. There are as many pieces as there are people. If each person completes his piece, the picture will complete, and the goal will be achieved. Note that, each person becomes engaged in her/his own individual project and can apply structured project management to that project.
45 Each job has a name against itThe first thing in assigning people to jobs is that every job must have a human being's name against it. Any of the above or organization names should be avoided as far as is humanly possible. If you are subcontracting something so that an organization is actually working on one of the jobs on your project, the name you should have against that job is the member of that organization whose ass is on the line for the successful delivery of that particular job. If at the beginning of a project you don't know who all the people will be, one of project manager’s priorities has to be that the unknowns get replaced by warm, living, loving human beings as quickly as possible.
46 People’s other commitmentsOne of the unconscious assumption project manager had made is that everyone would be available to the project full-time. Many times people had actually worked on the project on average between 1.5 and 2 days per week. All that everyone saw was a project that was years behind schedule. The original assumption about staffing levels (unconscious or otherwise) was lost along the way. Public holidays and sickness are all commitments that have to be allowed for. The point here is that we have to take people's other commitments into account. Project planning tools have facilities for doing this where you can allocate people to projects a certain percentage of the time.
47 People’s other commitmentsNote that this business also applies to yourself as project leader. Especially in software projects, project management is what the project leader does when he has any time left over from doing technical work. A rule of thumb that we offer is that you should reckon on 6–8 % of total project effort for project management: 6 % would apply to smaller projects (6 people or less). 8 % would be for larger ones (above 12 people).
48 People’s other commitmentsTo cover work of any member of the project team project manager need to figure on: project planning activities including scheduling, estimating and updating of PC-based tool files; project meetings to record progress or set targets; project reporting; day-to-day work assignment; all project team "people" issues including staff appraisals and reviews; day-to-day problem solving and troubleshooting; liaison with any suppliers (both internal and external); liaison with management; liaison with the customer;
49 People’s other commitmentsTo cover work of any member of the project team project manager need to figure on: liaison with related/dependent projects; normal ongoing recruitment; quality; quality plan/configuration management plan. In reality a large proportion of this work (75–80 % or even more) will be done by the project manager and/or team leaders. It is possible to work out the total amount of project management effort required in man-days or man-months.
50 People’s other commitmentsExample: 6 months project with a total effort of 22 man-months. Average number of people on the project is 3.7. 6 % project management overhead based on total effort Assuming 20 man-days = 1 man-month This gives 1.32 man-months = 26.4 man-days. Thus, over the 120 elapsed of the project, the project management overhead = 26.4/120 = 0.22 days (= 1.76 hours for an 8-hour day) per day. So, in an 8-hour day, the project manager can reckon on this many hours per day being taken up with project management work.
51 People’s other commitmentsExample: 12 months project and a total effort of 170 man-months. Average number of people on the project is 14.2. 8 % project management overhead based on total effort This gives 13.6 man-months. Thus, over the 12 elapsed months of the project, the project management overhead = 13.6/12 = 1.1 months per month. In this scenario, a project manager is likely to be busy pretty much full-time doing nothing but project management.
52 People’s other commitmentsExample: For each team the total project management overhead is 8% of the total effort of 56.7 man-months = 4.5 man-months: over the life of the project is 0.38 months per month: that is about 3 hours per day. For the project manager who now has a team of three people: the overhead is 3 people for 1 year = 36 man-months by 8 %, It gives approximately 3 man-months (2.88) or a quarter of his time over the year. This calculation assumes that all three team leaders are 100% as effective as the project manager and that there is no overhead involved in maintaining this hierarchy. In reality the project manager would increase his project management overhead in dealing with the team leaders.
53 Team structure Monolithic team or Flat structureThe project manager gets to be totally hands-on. This requires a large amount of project management by the project manager, which has to be allowed for in schedules. Hierarchy or Team structure Frees up project manager significantly to manage other projects and/or do technical work. The following points apply: The project management effort required of the team leaders has to be allowed for in schedules. Handing over responsibility may initially involve the project manager in more project management until she is happy that the team leaders can be fully relied on.
54 Assign people to job For any job on your list, and for any person in your team, the following possibilities apply (a five categories): can do the job and wants to do it can do the job and is prepared to do it can do the job and isn't prepared to do it can be trained/instructed into doing the job cannot do the job You now need to assign the jobs to the people so that the project will get done.
55 Assign people to job Category 1: Category 2: It is the ideal one:In this category, the person can do the job and likes to do it. If you can get a person doing what he or she wants to do, you have harnessed the greatest power on earth. Category 2: It is still OK: You're happy that the person can do this job – perhaps they've done it before, or you know it's within their capabilities. There may be more or less persuading to be done to convince them to do it. There is a limit to how often you can persuade people to do things they don't really want to do. You can maintain that for the duration of the project, you should have no real problems.
56 Assign people to job Category 1: Category 2: It is the ideal one:In this category, the person can do the job and likes to do it. If you can get a person doing what he or she wants to do, you have harnessed the greatest power on earth. Category 2: It is still OK: You're happy that the person can do this job – perhaps they've done it before, or you know it's within their capabilities. There may be more or less persuading to be done to convince them to do it. There is a limit to how often you can persuade people to do things they don't really want to do. You can maintain that for the duration of the project, you should have no real problems.
57 Assign people to job Category 3: Category 4:You have got a problem: the person can do the job, but won't. Who knows what the reason is? Maybe she/he is done it too many times before and is bored, maybe he feels he's not being paid enough. Basically what you've got to do here is to cause this situation to revert to either Category 2 or Category 5. Category 4: For it then provided: You are prepared to put in the training time and money and you allow for training time in the project schedule and you allow for the extra management overhead and you're prepared to run with the risk that it might not work out It can often work out very well. For Category 4: In fact, you can often find yourself in a Category 1 situation because you may well have pushed the person into a more challenging job than she/he wanted to move into.
58 Assign people to job Category 5: You have a major problem.It may take you time to arrive at the conclusion that the person cannot do the job, but if you eventually do so, you need to find jobs within your project that the person can do - failing that, the person belongs outside the project. It may take several iterations before you get everything nicely balanced, that is: utilization of everyone less than or equal to 100 percent all training/instruction needs identified (note that this generates new jobs for the job list) a feeling that, by and large, everybody will be happy with the jobs they've been assigned to do In this balancing act of matching people to jobs you can obviously get into problems of over- or under-utilizing people, and this is where something like a computerized project planning system is useful, though not essential.
59 Manage expectations & ContingencyThis is a step 5. If you have carried out steps 1-4 as, then what you have done is you have built a working model of how your project might unfold over time. You know what's going to be delivered, you know when it will complete, you know how many people you need and a whole load of other useful information. But what will you do if it doesn't turn out like your model predicts? Do not forget that everything that is in the plan is a prediction, a guess, a shot in the dark, a gamble. You need to ask yourself the question: what will I do if it doesn't work out like this?
60 Contingency People would expect to see a line item called ‘Contingency ‘ in project manager’s plans. If people didn't see this, they would assume one of two things: the more charitable of the two would be that it was an omission on your part; the other would be that you had taken leave of your senses. Finding contingency You can use functionality, delivery date, effort /cost and quality to help you build in your contingency. They would believe this because in omitting contingency, it would imply that you felt confident you could predict the future.
61 Contingency FunctionalitySome projects get structured such that on some happy day in the future, somebody will pull the great lever and the whole system will power up and work perfectly. Either it all works perfectly on the promised delivery date or … it doesn't work at all. You can certainly organize your project this way, but then you are really asking for trouble: you have given yourself no room for maneuver, no fallback position. As an alternative to this you can do what is called phased delivery. At any point, if you find you have reached for a milestone too far, you can always fall back on the last version you delivered. Is there some minimal set of functionality your project can deliver which will get your customer off the ground ? Can you add some more functionality and some more and some more ?
62 Contingency Delivery date and effortYou can add contingency using either of these merely by adding on an additional percentage to allow for contingency. Typical numbers tend to be in the range 10–15 percent. As a general rule, the more you can get the better. You can add the contingency: on a blanket basis, across the entire project on a per phase basis, that is, to each phase to those jobs on the critical path It is probably better to aim for adding a percentage onto the delivery date: It often means you can hold onto people for that extra period of time, and so achieve an even bigger contingency on the effort. Certainly the more chance you have of your model being seen to be right and hence, of having a successful project.
63 Contingency Quality If you can measure the quality of your project deliverables, then you can use these as bargaining counters in the contingency game. In the development of a software system you might use mean time to defect (MTTD) as a measure of quality Then you might aim for an MTTD of, say, 2 days, but in a pinch you'd be prepared to settle for 1 day or 1.5 days. Again, you gain some room for maneuver, some margin for error.
64 Manage expectations & CommittingSooner or later in projects we have to commit. In doing this, people basically make a promise and then try to make that promise happen. If everything turns out as people predicted, then they are heroes. Otherwise their name is mud. You should try and leave it to as late as possible in the project. The longer you can get away with not having to make this promise, the better for all concerned. Each day that passes you find out more about the nature of the project, and all of these details, when fed into a model of your project, increase the likelihood that the promise you make will come true.
65 Manage expectations & CommittingSome thoughts about committing. Know what your customer is expecting. What he is expecting will be based entirely on what you have led him to believe. Check and see what he could actually put up with at a pinch. Be sure that your development schedule enables you to deliver this first. Build a number of demonstrations and/or prototypes into your schedule so that your customer can get her/his hands on the system early You can verify that you have read her/his expectations correctly. A retreat to a fallback position need not be an ignominious thing It can be presented as a master stroke of planning and forethought
66 Manage expectations & CommittingSome thoughts about committing. See what is required to go beyond her/his expectations and plan to go there if at all possible: It will only wow her if you have given her all of what her basic expectations were. Don't spring surprises on your customer. It is only when they get the impression that you are not being straight with them that they react badly. Customers are very forgiving people once they are treated as intelligent human beings. Some things have no margin for error. Know which things on your project are like this, watch them like a hawk, and make sure they happen.
67 Manage expectations In the beginning of the project customers and/or bosses often want to know project’s end day and cost. The only time you can accurately estimate a project, that is commit to a fixed schedule and effort, is when all the design is finished. Two fixed-price quotes “I can only give you a date/effort by which the design will be done. At that point I can give you a date/effort for the rest.“ If customer will have her/his design so that if she/he don't like your bid for the implementation she/he can take the design elsewhere. Often you are also required to bid fixed-price for a job when you are very early in the product development life cycle.
68 Manage expectations Parkinsonian estimatingOften pressure is applied by telling you the end date by which the system must be ready and the size of the team you're being given to deliver. A Parkinsonian estimate, worked back from the end date, can show the impossibility of what you are being asked to do. It can be done very quickly. You fit your six (or whatever number you use) phases back from the end date. Typically the effects you get are things like: to make the deadline the development should have started two months ago; the deadline can only be achieved if coding takes two days; or the deadline can be achieved if we don't do any testing.
69 Manage expectations Load the estimateIf you are put in a position where you have to give a fixed- price quote, then you must load the estimate to give yourself sufficient room for maneuver. "We don't know how big the job is, Mr. xxx, so given our estimates, see, and our level of knowledge at the moment, we have to assume worst case scenarios, so this is the reason for our pricing. If, at the end of the design phase, we find that we overestimated we'll be more than happy to pass the reduction on to you. Oh, and by the way if anyone is telling you differently … they're wrong.“ If you have done your estimates properly and believe in them, then you hold the moral high ground. If you commit to something you cannot achieve then you will preside over a catastrophe and you will be left looking fairly silly.
70 Manage expectations Play the change control gameIf you are forced to make a fixed-price bid, be sure you deliver it with all the relevant fine print. State explicitly, and in excruciating detail, what was and wasn't included and the assumptions you made. As other items come to light in the course of the analysis and design phases, you can play the change control game where every new item becomes a change to the contract. Contingency, or margin for error, can be thought of as the gap between your fallback position and your actual goal.
71 A similar ‘sounding’ termsThe ‘Procedure’ term A manner of proceeding A way of performing or effecting something They are rules with expectations of compliance, and penalties if not followed. There is a degree of formality associated with procedures. A fixed, step-by-step sequence of activities or course of action (with definite start and end points) that must be followed in the same order to correctly perform a task. Repetitive procedures are called routines. A set of established forms or methods for conducting the affairs of an organized body such as a business, club, or government.
72 A similar ‘sounding’ termsThe ‘Method’ term A procedure, technique, or way of doing something, especially in accordance with a definite plan. An established, habitual, logical, or prescribed practice or systematic process of achieving certain ends with accuracy and efficiency, usually in an ordered sequence of fixed steps. As a ‘problem solving’ Step-by-step approach consisting of (1) identifying and defining a problem, (2) accumulating relevant data, (3) formulating a tentative hypothesis, (4) conducting experiments to test the hypothesis, (5) interpreting the results objectively, and (6) repeating the steps until an acceptable solution is found. As a ‘sciences’ Rigorous, systematic approach, designed to eliminate bias and other subjective influences in the search, identification, and measurement or validation of facts and cause-effect relationships, and from which scientific laws may be deduced.
73 A similar ‘sounding’ termsThe ‘Algorithm’ term: Step by step procedure designed to perform an operation, and which (like a map or flowchart) will lead to the sought result if followed correctly. Algorithms have a definite beginning and a definite end, and a finite number of steps. An algorithm produces the same output information given the same input information, and several short algorithms can be combined to perform complex tasks such as writing a computer program. Suitable for solving structured problems (amenable to sequential analysis) algorithms are, however, unsuitable for problems where value judgments are required. A cookbook recipe, a diagnosis, a problem solving routine, are some common examples of simple algorithms.
74 A similar ‘sounding’ termsThe ‘Methodology’ term: A set or system of methods, principles, and rules for regulating a given discipline, as in the arts or sciences. A system of broad principles or rules from which specific methods or procedures may be derived to interpret or solve different problems within the scope of a particular discipline. Unlike an algorithm, a methodology is not a formula but a set of practices. The study of the principles underlying the organization of the various sciences and the conduct of scientific inquiry.
75 A similar ‘sounding’ termsThe ‘Technology’ term: The branch of knowledge that deals with the creation and use of technical means and their interrelation with life, society, and the environment. The purposeful application of information in the design, production, and utilization of goods and services, and in the organization of human activities. Technology is generally divided into five categories (1) Tangible: blueprints, models, operating manuals, prototypes. (2) Intangible: consultancy, problem-solving, and training methods. (3) High: entirely or almost entirely automated and intelligent technology that manipulates ever finer matter and ever powerful forces. (4) Intermediate: semi-automated partially intelligent technology that manipulates refined matter and medium level forces. (5) Low: labor-intensive technology that manipulates only coarse or gross matter and weaker forces.
76 A similar ‘sounding’ termsThe ‘Best practice’ term: They are recent, emerging out of management consulting domains. A best practice is a method or technique that has consistently shown results superior to those achieved with other means, and that is used as a benchmark. In addition, a ‘best’ practice can evolve to become better as improvements are discovered. Best practice is considered by some as a business buzzword, used to describe the process of developing and following a standard way of doing things that multiple organizations can use.
77 Questions ? 77 77