Introduction to software project management

Contents:

Preface

In rather short, but eventful career as a computer programmer I have seen many different project fail. In fact, there were very few projects I worked on that can be called a success. I decided sometime ago to study proper techniques of project management in order to avoid repeating mistakes executed with Swiss watch precision by management staff at most small to medium corporations. Here I present to the reader my personal notes that I have taken during my study. My aim was to leave for myself hints for each important aspect of project management. A refresher notes. By no means notes presented here should be used as complete reference. I am sure there are plenty of mistakes that will take me some time to fix - send me a note with your comments/ suggestions.

Legal stuff: I provide this guide as is, without any guarantees, explicit or implied, as to its contents. You may use the information contained herein in your computer career, however I take no responsibility for any damages you may incur as a result of following this guide. You may use this document freely and share it with anybody as long as you provide the whole document in one piece and do not charge any money for it. If you find any mistakes, please feel free to inform me about them Tom Kitta. Legal stuff aside, let us start.

Guide version 0.11 last updated on 28/01/2007.

Software development has inherit problem with determining the time it takes to complete it. Software programming is quite different than say, nail production. When one produces nails it is known how many nails machine produces per hour. If you need to produce x number of nails figuring the time it takes is easy. If you need 12h of time, you know that one of your workers can handle the overtime and omitting for the sake of argument certain safety concerns, your worker will be as productive at hour 1 as hour 12. Unfortunately, software development is much harder than nail manufacturing. There are many more unknowns - risks that have to be accounted for. In order to attain rapid software development, four different aspects have to be considered. These are:

• Risk management
• Avoiding common mistakes
• Practicing development fundamentals
• Following practices leading to best possible schedule

The rest of this guide will discuss each of above four elements of project management. All of above are equally important, if any of above four is omitted then the whole structure might fail. The reason for "might" is the risk based aspect - as mentioned before things may go right or wrong. It's all about leaning in favor of successful resolution instead of using methods that increase the chance of failure. One of the methods that increase risk, but are widely used due to their simplicity, is programmer total commitment. This disorganized way of project management has its successes, however these successes are a result of inefficient, hard work - not of smart work that can be achieved by following above four principles.

• The speed with which project is completed depends on four competing factors that are pooling the project in their respective directions.
• To achieve rapid development, you need to optimize all four factors listed underneath:
• People - select top talent that is motivated in well organized team structure
• Technology -
• Process - create customer oriented software that incorporates high level of quality achieved with help of development fundamentals. Manage risks with lifecycle model and efficient use of resources.
• Product - remember that size does matter, flexible requirements help in shortening of schedules.

• People
• Management decreased developer motivation.
• Under-trained developers, developers with low qualifications.
• Keeping problem developers (non-team players) on the team against wishes of all other team members.
• Company encouraged developer "heroics", emphasis on "can-do" attitudes.
• Adding people to projects that are over-running their schedule.
• Working environment that prevents developers from focusing on their work. Customer interactions that are too frequent or lead to open conflicts.
• Unrealistic expectations, usually in the area of project scheduling, wishful thinking.
• Absence of executive project sponsorship, absence of agreement between all parties involved in the project.
• Absence of customer involvement in the project causing delivery of software that doesn't meet customer expectations which in turn cause feature creep.
• Involving developers in company politics more than is necessary.
• Process
• Schedules that are to short for the project at hand - too much emphasis on optimism.
• No risk management or insufficient risk management.
• Problems with contractors (part of risk assessment)
• Luck of, or insufficient project planning. Throwing out plans when placed under excessive pressure to complete project. Deliberately omitting non-code related activities, like design, due to excessive pressure.
• Spending excessive amounts of time on project approval and budgeting.
• Poor design and poor quality assurance.
• To few controls placed on the development process causing schedule slips to go unnoticed.
• Attempting to enter project "polishing" stage to early or more than once (frequent attempts to get it shipped).
• Thinking that project which is in trouble can be saved by "catch up" later on.
• Product
• Too many requirements, attempting to build systems that can do everything.
• Adding to many new features to the ongoing project - feature creep.
• Allowing developers to use new technology project for reasons other than project requirement.
• Attempting to treat software research as regular software development.
• Technology
• Silver bullet technology syndrome, over-estimating benefits of new tools and technology.
• Changing tools or methods in the middle of the project.
• Failure to keep code backups, no source control software.

• Development fundamentals reduce time and cost needed to develop software. However, they are not sufficient to develop software quickly, they are only necessary conditions for rapid development (ie if you don't have them you are almost certain to fail, but if you have them you are not guaranteed success).
• Development fundamentals can be divided into three areas that share fuzzy boundaries, non-technical, technical and quality assurance
• Non-technical fundamentals control all aspects of well known trade-off triangle (time, cost and product quality)
• Ability to estimate project size. Once project size is narrowed down, ability to estimate effort needed to develop project based on project size. When effort needed is known, rough schedule can be created.
• Ability to plan and stick to the plan under pressure. Planning can be further broken down into these components:
• Team members, team size and team organization.
• Lifecycle model choice.
• Control over feature set.
• Measuring progress through milestones (or micro milestones), reports, meetings etc.
• Recording project statistics, at least cost, schedule performance and quality (three aspects of trade-off triangle).
• Technical fundamentals require knowledge of programming principles and experience in their application.
• Ability to manage requirements can be further broken down into smaller parts:
• End-user or customer involvement in requirement gathering process, for example through interviews
• Making sure requirements are complete
• Preventing frequent changes to requirements
• Using requirements analysis methodologies, like object oriented analysis
• Good graphical modeling of whole or partial systems, for example database diagrams
• Good design
• Good design starts with a choice of design style, for example object oriented design
• Each design style has its own set of design concepts, for example inheritance
• Using patterns to solve well known problems
• Use of design software for large projects
• Production of code that is of high quality
• Naming and inline documentation conventions, rules for creation of new files and packages
• Standard practices that lead to good code, like use of constants for values that don't change over time
• Error detection
• Unit testing and integration rules
• Code refractory and optimization
• Use of other software programs in creation of code, for example IDE choice
• Management of software configuration deals with keeping the project feature set under control, most important feature set management technique is a change board. It decides what features are in and what features are out.
• Quality assurance is more than just testing
• Ensuring that code created is of high quality (as described above). Code used for testing purposes should also be of high quality.
• Focus on defect detection in early stages of project development, not just in code but also more importantly in earlier stages, such as requirements gathering.
• Re-writing of all pieces of code that have high defect rate.
• Remember that testing final product can show that it is of low quality but it cannot prove its of high quality.
• Reading code is a good bug catching activity
• Formal inspections are used to check adherence to project specifications on "industrial" scale. Each inspection team member has a specific role. Inspections are done on each major stage of project development. Inspections start with requirement inspection and end with final product inspection.

• Risk management in general is a relatively new discipline, with software risk management playing the role of one of it's most recent advances.
• Risks come in three different forms, each associated with a branch of the "trade-off triangle". Software projects deal with risks associated with schedule, cost and quality.
• The goal of risk management is to minimize crisis management and failure and fix management styles while at the same time maximizing the prevention and elimination of problematic areas of the project.
• In order to achieve above goal risks have to be assessed first and then put under control.
• Risk assessment is made of:
• Risk identification
• Likelihood of events identified as risks
• Impact study of each risk, with priority given to most dangerous scenarios
• Risk control is made of:
• Preparing list of actions that have to be taken when each predicted event takes place
• Making sure risk resolution plan is followed
• There are too many different types of risk to be enumerated here. Risks generally are mirror image of best practices, for example, inadequate design is a risk, while good design is a best practice.
• Risk exposure is the likelihood of the event multiplied by the impact the even will have. Events that are common but have small impact will produce the same risk exposure as events that are rare but have large impact.
• Risk resolution techniques can be as simple as avoiding the task that is risky, to as complex as development of contingency plans.
• Risks don't stay static throughout project development, they change. Risks need to be monitored. A good way to monitor risks is to keep a list of the most current top 10 risks.
• Be aware of projects that are very risky, projects with more than 90% failure probability. These projects don't pay in the long run.

• There is no one single best practice that leads to the best software development method. For each specific project a method has to be chose that is appropriate for it. For example, mission critical software products have to be of much higher quality than a screen saver software.
• Not all projects need to optimize their development speed, many upper managers ask for speed but mean other things. For example, client will talk about quick development when they really want to minimize project overall cost.
• Unless product has a strong schedule constraint development speed might not be of top priority. If speed is not the most important factor, concentrate on quality.
• Remember, you can deliver projects with only 2 branches of the trade-off triangle.

• There is an absolute limit on the minimal time it will take to complete any given project.
• Projects cannot have 100% probability of completing on any given time because they involve risks (not everything in a project is certain) thus we are dealing with probabilities of completing on a given date.
• Projects that are rapidly developed can be seen by customers as slow because they don't provide a lot of feedback as to project progress.
• Remember that cutting time from the top most (done 1st) stages of the project will force you to pay back in time many times over in lower stages of the project. For example, design flow will cost much more to fix in the construction phase than design phase.

• Lifecycle model gives order to operations performed from the time of project start (when the software is just an idea) till project completion (when project is absolute, no longer supported).
• Every project uses a lifecycle model, even if such model is not defined at project's start. You are using it even through you don't know about it.
• Every lifecycle model (other than code and fix) has the following essential phases:
• Software concept - initial idea
• Requirements gathering and analysis
• Software design
• Detailed software design
• Coding
• Debugging
• Testing
• Software delivery, project completed
• If an organization doesn't know what life cycle model they are using when asked, it means they are using code and fix lifecycle model.
• Code and fix model was introduced together with the earliest software, in 1950's.
• Through most organizations see this model as "evil" it does have few advantages and legitimate uses.
• This model doesn't require any training - its natural, everyone knows how to use it without any training.
• It shows signs of progress immediately since no formal planning is performed, programmers jump into coding phase right after initial software concept gets approval of upper management.
• This model is good for tiny projects or for throw away one time only code.
• For larger projects the list of problems with this model is very long, lets just leave it as an exercise to the reader to come up with a list based on premise "if you don't plan ...".
• The most basic and earliest organized life cycle model is called waterfall lifecycle model
• This model goes from one stage to the other of software development in linear fashion
• The waterfall model is old and has many known weaknesses, however, for some projects it is still very useful. It works well with complex projects that have very well known architecture. This model places emphasis on software quality, not on speed or cost of the software development.
• Main weakness is outlined above already, most projects don't have requirements written in stone. Waterfall model is very inflexible - it is not the model that accepts change even in moderate amounts. It is a fact that most end-users, the customer that requests the project, don't know what they exactly want before project is commenced. Thus, the waterfall lifecycle model is not practical when faced with realities of everyday life.
• Other problems include excessive amounts of documentation and very few signs of progress.
• Spiral - cinnamon roll model
• The main idea behind creation of this model was risk control. This model is designed to minimize risks associated with software development.
• This model divides the whole software development into a series of iterations. Each iteration can include the following five steps. Note that these are only basic steps iteration can include, depending on aim, some steps can be omitted, some may be added.
• Plan out iteration objectives, prioritize objectives, plan alternatives.
• Identify risks associated with objectives and route to their resolution.
• Develop objectives (for example code).
• Check whatever objective aim was achieve, quality assurance.
• End current iteration, start planning next iteration, if one is needed.
• Note that iteration(s) are needed for each of essential software phases.
• This model is highly customized, the main idea is that of an iteration. Some iteration can take a form of another lifecycle model. For example, you may start with "regular" spiral model and finish with waterfall model once all risks are taken care of.
• This model has one noteworthy disadvantage. All this flexibility comes at a price, this is one of the most complex lifecycle models. The trade-off is simplicity for flexibility. Note that most simple models like code and fix or standard waterfall are easy to master.
• As deficiencies of waterfall model became apparent a number of modified waterfall lifecycle models were created. Each of these models resembles standard waterfall in that it is easy to learn, but attempts to fix at least one weakness of the standard waterfall model.
• Sashimi lifecycle model is a standard waterfall model with overlapping stages. It allows more flexibility in movement between consecutive phases. This comes at the price of unclear progress as phase boundary is fuzzy.
• Waterfall with sub-projects lifecycle model trades increased (perceived and maybe real) speed of development for increased risk. In this model after software architecture is designed (on high level, not detail) project is divided into a number of small waterfall based projects that work in parallel. The idea is that some of these will produce results quicker than others. Problems could arise if unforeseen system inter dependencies are discovered between projects that are assumed to be separate.
• Risk reduced lifecycle model was already discussed under spiral model as a possible modification. In this model risk is reduced by using spiral model for initial project design and proceed with standard waterfall model from detailed design till project delivery.
• Staged delivery model proceeds as standard water cycle model until end of design phase. At this stage the project is divided into a number of phases that include all other stages of waterfall model. Important functionality is implemented in early stages allowing the customer to use the product as soon as few stages are complete. The main disadvantage of this project deals with large amount of planning needed for each stage. This model can also be adopted for projects on tight schedules. When a deadline that is immovable is reached, product completed some of its planned stages and can be shipped with most important functionality already implemented.
• Evolutionary prototyping model starts with a prototype that implements as many prominent visible features as possible. This initial prototype is then modified as per customer input until it is shipped as completed software product.
• This model is great for projects that have rapidly changing requirements, projects where customers don't know or are unsure as to what they want.
• The main disadvantage of this approach is related to the risk that uncertain customer brings to the project. If we don't know what the customer wants, we cannot know how long it will take to build.
• Care must be taken to avoid morphing evolutionary prototyping model into a code and fix model.
• Evolutionary delivery model is a hybrid of evolutionary prototyping and staged delivery. In this model each prototype completed and a stage.
• There are many more lifecycle models to choose from. Each project is different. A choice of lifecycle model should be made with these point in mind:
• How well do customers know what they want.
• How well does the developer know system he needs to build, its architecture.
• What is the overall system quality that is expected.
• Future version planning emphasis.
• What is the level of risk in this project.
• What is the schedule like, is there a deadline that cannot be moved.
• How much visible progress does the customer want.
• How experienced is the development team.

• Project planning is based on the ability to estimate project size and create based on size estimate project schedule.
• Software schedule estimation is "hard" because initial estimates are based on process plagued by multiple unknown factors. Thus, initial estimates are very inaccurate. As more is known about the project, schedule can be refined.
• At product definition stage there are many unknowns, thus projects estimated effort (and size) has a potential error of +500% and -%30 (with some large confidence interval, say 95%).
• Confidence intervals are used in statistics to measure how sure is the statistician that the phenomenon measured will fall within the range computed. Common confidence intervals are 90%, 95% and 99%. As confidence interval approaches 1 the range widens since it has to account for many unlikely events. 95% confidence interval is a good start.
• It is a good idea to refine project schedule after each milestone or stage is complete. Schedule should be more precise as it is based on more stable data.
• Parkinson's law: work expands to fill in available time. This implies that schedules that assign to much time to a project just to be safe risk loosing efficiency.
• In order to produce an estimate, the following estimates have to be completed:
• Product size estimate - can be number of lines or number of function points (IBM method) or using special software
• Product effort estimate - how many man-months will it take to complete project of given size
• Schedule estimate based on effort needed, easy compared to above two steps, many formulas exist for automated computing
• Function points are also known as IBM method of 1984. A function point is assigned per certain level of complexity of either input or output to the software system.
• Jones's First-Order estimation is a method of deriving a rough estimate from function point count. A table is used to determine, based on software class, the exponent to which function point count needs to be raised in order to get number of months project will take to complete. For example, for average business software the exponent is 0.43.
• Lines of code make for an easier then function point estimate, however, same task written in different language requires different amount of code lines. For code line count only lines with the actual code are counted. Tables are used for projects that will need at least 10000 lines of code. Anything less than 10000 is usually done by single person and is correlated to abilities of that individual.
• The following are best practices for software estimation:
• Never make "quick estimates". If you are forced to provide a number, make sure you provide a disclaimer as to its luck of accuracy.
• Don't argue about the estimate or schedule - they are fixed and non-negotiable. Instead try to change inputs that produce the estimate.
• Commitment based scheduling, where each developer commits to a schedule has a major problem related to natural tendency of developers to be too optimistic. The encouragement of optimism by managers makes for very inaccurate scheduling.
• When estimating make sure you compare results to similar past projects. Make sure your estimates include trivial, common or obvious tasks.
• When presenting an estimate use a range and/ or confidence interval. You don't need to be precise in range estimates, for example, you may say that in the worst case project A will be completed in the middle of December.
• The best tool in project effort estimation is company's historical data.
• You cannot refine project estimate before project start, even with more time. Refinement can only occur once project progresses.
• When project is missing milestones, multiply the project estimate by 1 + amount of slip / old estimate - current project progress. For example, if a project with original schedule of three months is late one week, 6 weeks into project, then new schedule = 3 * {1 + 0.25/(3-1.5)} = 3 * 1.166 = 3.5
• Project almost never catch up once they are behind unless project cost and/ or project features are changed in order to decrease project effort.
• Schedule can be derived from the following formula: schedule in time periods = corrective factor * man time periods ^ 1/3. Most typical time period is a month. Corrective factor varies, it can be anywhere from 2.5 to 3.5, with 3 a good guess.
• Schedules can be compressed:
• Schedules can be compressed, however, compression of a schedule requires exponential increase in required effort.
• Compression factor = desired schedule / initial schedule
• new effort = initial effort / compression factor
• It is believed it is impossible to achieve compression factor of less than 0.75.

• It is rather easy to go from project size to project size and then to schedule estimate when compared to the task of getting schedule accepted.
• Higher management almost always pushes for overly optimistic schedules.
• Problems with schedules can be traced to wishful thinking of management/ customers and poor negotiation skills of the project manager.
• Most common scheduling mistakes:
• Start project polishing procedures earlier than planned
• Not adhering to plan when project runs behind schedule
• Luck of good project planning
• Too much pressure on development team causing dramatic increase in error count and loss of team morale.
• Forgetting about the customer.
• Remember that you cannot cut out of the schedule non-code related activities since skimping on them will cause dramatic, as high as 10 to 100, increase in coding and testing.
• Good negotiation technique that is easy to learn is based on creation of "win - win" scenarios for both sides of the negotiation. This technique has four aspects that need to be followed:
• Make sure objective criteria are used while discussing the schedule - the most important criteria is related to the schedule for given work - this is written in stone and cannot be changed, what can change is the work effort or expected cost (trade-off triangle).
• The focus of the conversation should be aimed towards interests of both parties, not their positions/li>
• The discussion is about the schedule, not people on either side of the table - as little emotions as possible
• Aim at options that are going to benefit both sides, play with the trade-off triangle
• Insist on the schedule you have come up - its better to stand by and weather the rain then be under the drainpipe later on, once the project gets out of hand if your schedule is not followed.

• The supreme goal of every software project is to create a product that is going to satisfy product users - customers. When customers are happy, everyone else in the company is happy.
• Not all solutions created by the developers are good for the customers.
• One of the most costly mistakes that can plague project development are related to development of products that end-users don't want to use. Creating something that was not expected by the customer leads to massive waste of money, as ultimate goal of producing what the customer wants is as (almost) as far away as when the project commenced.
• In order to produce product that customer(s) want, the following techniques of communication can by applied:
• Requirements analysis - you need the "real" requirements, use techniques like user interface prototyping and focus groups to find out what customers really want to see in the product you are creating for them.
• Project planning - you need to find out who you need to satisfy and establish good communication with that group of people.
• Design - what you need to create is never written in stone, also, things will evolve later on as no project stays final for long. Thus, plan to change, create flexible designs (but not too flexible).
• Actual coding - customers like to see project progress, it makes them feel safer, your job (as well as everyone else's in the company) is to keep customers happy - thus make progress visible to your customers.
• What customers expect and what developers can deliver frequently is not written on the same page. This leads to problems later on in project's life. Make sure customers know what they should expect as far as project cost, speed and functionality is concerned. Never lie to your customers, as a lie will sooner or later come out of the closed and poison your relationship with your customer.

• Developer motivation is the most important factor in determining that developer's productivity. The difference in productivity between unmotivated and very motivated developer can be as high as 1:10.
• It is hard to measure effects of motivation on productivity since motivation is not a material entity.
• Different people are motivated by different things, for example, software developers are motivated as a group by different things than average manager. The difference is quite wide - developers frequently motivated by opposite factors than their managers.
• Some of the most important motivating factors for developers are:
• Achievement recognition - set a goal that developers can aim for, be it fastest code or shortest amount of code. Let developers take control of the project, like setting up their own ambitious schedules.
• Growth in their chosen IT profession - make sure your staff is up to date in their IT skills. Developers love to learn new tricks, make sure you train them or allow time off for training.
• Enjoyable work - developers like to do important tasks that involve use of their technical skills. The dislike producing low quality products. Make sure your developers are distracted as little as possible by people or administrative tasks.
• Ability to have fulfilling family life - when rewarding developer remember that he would rather have time off than sit at the desk for 10 more hours.
• Other things that will make developers happier and thus more productive:
• Flexible office hours - it is a great idea to let the programmers choose their office hours as people are most productive (and less sleep deprived) at different times of the day.
• Private space, a room for every programmer is a good idea.
• Good PC support, up to date hardware, easy access to all office supplies.
• Easy access to newest reference books.
• In order for something to motivate an average developer it has to be logical - for example, a deadline that is not achievable when careful project planning is done will not motivate developers but their managers. Only a deadline that is achievable (but possibly hard to achieve) is going to motivate you development team.
• In order for your developers to stay at your company you need to reward them for their work frequently. Don't underestimate the power of non-monetary gifts. Team t-shirts and other small items are reminding developers just how much you appreciate their hard work.
• People by nature like to discover things, they like to travel and they perform better if they are part of a study. Take advantage of this natural tendency, also known as "Hawthorne effect". People do better if they know they are part of an experimental software group.
• Avoid these activities that kill morale - these are opposite to the factors that increase morale.
• Don't lie to your staff - fake deadlines are easy to spot.
• Too much pressure is exactly as it sounds, too much. Your stuff will loose their ability to work efficiently.
• Make sure that managers which don't know too much about technology stay away from your stuff. This also applies to sales and marketing department members - their role in the company doesn't include developer harassment.
• All decisions that effect developers should be discussed with them. It is a bad idea to make decisions for your staff, since they no longer feel that they are part of the team. They are no longer on a mission but are experiencing hardship.

• Team is made up of up to 10 people that agree on common goal and way to reach this goal. People that make software teams also have complementary IT skills.
• Performance differences between teams are almost as great as performance differences between individual developers.
• All high performing teams have common characteristics which are listed underneath:
• All team members share the same goal, this team mission is well understood by every team member.
• All team members share the way team goal is to be achieved.
• Teams are separate entities, there is a sense of pride of being in one team versus another, competitiveness vs. other teams. Members of a team are no longer individuals - they are team members. Team success is much more important than individual success.
• Every team member is an expert in his or her area. Team has to have balanced technical skills to be effective, no amount of work is going to push a project if team members simply don't know how to do push. Non-technical, soft skills are also needed in support roles.
• Every team member trusts and respect every other team member.
• Working with the rest of the team is very enjoyable for every team member.
• Team members communicate well with every other team member, sometimes using team exclusive terminology.
• The following is a list of what can go wrong with a team in addition to negative of characteristics listed as good team properties.
• People that are "members" of a team but chose to sabotage team efforts. These are problem employees and they should be removed from the team as fast as possible. Ignorant and secretive as to their work people have no place on a development team.
• Factors that prevent teams from doing their job, like inappropriate management involvement.
• As with individual developers, teams need to be recognized for their hard work.
• The whole team shares successes, but as in a marriage, the whole team shares failures as well. Everyone is contributes to team success, thus everyone is accountable for team mishaps.
• Software managers should be concerned with clearing development roadblocks and allow the team to be more efficient. His or her role is that of a supporter, product could be developed without the manager but not without the developers. Managers should deal with non-technical issues.
• Technical leads are programmers with extra responsibility. They are responsible for technical aspects, like design, on a single team. They should leave as much non-technical work as possible to managers.
• It is OK to let teams sit idle for short period of time - it is much more expensive to build new team from scratch later on.
• Teams, as individual developers, should be kept away from company "politics".
• As with lifecycle models, there is no one perfect team structure. Team structure is the way team members are organized inside the team.
• There are three main team types, you choose a type based on project objective. As there is no best lifecycle methodology, there is no best team structure - it all depends on what you want to achieve.
• The following list outlines most common development team models:
• Business team - most common in the industry due to its simplicity. This team has a lead developer with a group of developers of equal standing. Lead developer is usually the team contact person for the management and the developer who has the last say in technical disputes. This team structure is very flexible, it can work on any project, but its flexibility comes at the price of not being the best model for any particular problem.
• Surgeon and nurses team - in this team bulk of design and code is done by a star developer. Other team members specialize in different areas of surgeon support. This model is well suited to projects that either have a good plan or need creative mind.
• Skunk works - if your goals are extraordinary you need to loosen usual rules. A Skunk Works is often a small (in order to reduce communications overhead) team that develops something in a short time with minimal management constraints. Can be used to spearhead product design that later will be developed according to the usual rules. Can be used for secret projects - great for research projects.
• Feature selection team - has representative from every party concerned, ie development, management, marketing, quality assurance etc. Good for problem solving areas as it has great decision power due to representation from the whole company.
• SWAT/ Commando teams - used for emergencies made of highly trained individuals that form a permanent team structure. All members are trained in specific area of development, for example in ASP.NET. Used for both problems situations and where there is a need to quickly execute a plan.
• Firefighter team - this team can be assembled and put into action at moments notice, at any time. Used for emergencies - problem resolution.
• Theater - developers play different roles with the manager acting as the producer. Roles developers are assigned don't change. Good for multimedia projects which have to do a lot with art.
• Team models are applied to solve three main types of tasks:
• Specific problem resolution
• Research and development
• Plan centered execution
• On every team there should be a person responsible for the conceptual integrity - a team leader.
• On large teams communication overhead can slow development. Break large teams into smaller ones, of no more than 8-10 people each - form a hierarchy. It's a good idea to use military as the model, where squad leader is the person that has the most people under him (8-9). Officers have at 3-4 people they directly command.

• One of the most common reasons why planned schedules don't reflect real schedules is the problem of creeping project requirements.
• You need to take control of the feature set:
• Use minimal documentation - avoid wasting time on non-essential document preparation, prevent documents from becoming obsolete due to problems with their maintenance, constrained design - luck of flexibility that will allow developers to create features faster.
• Make a short introductory project paper, about 5 to 10 pages in length.
• Common vision specification - one time only approximation.
• Create manual that will serve as a specification.
• Create visual story book - pictures are worth 1000 words each.
• Create project vision as to what is the overall mission/ goal.
• Make sure you don't omit critical features.
• Don't gold plate anything.
• Be advised that minimal specification will limit your abilities to participate in parallel activities.
• Remember that you should use minimal specification only when project allows for flexibility - your goal is to trade speed for some fuzziness in the overall design your team is going to use.
• Remove and clean requirements - if something is not needed it can be removed, if it doesn't have to be coded and planned for then it doesn't require any effort. This is one of the best ways to shorten your schedule.
• Remove what is not needed.
• Simplify everything that is needed.
• Use less ambitious options for most time expensive features.
• Understand sources of changes and how to control them - note that developers, end-users and marketers will try to change the requirements. Avoid commitment to impossible goals, frequently proposed by people that want to create a "killer" application.
• You should not assume that there never will be any changes, or that you can prevent any change requests from occurring. Needs of your customers will dictate what you need to create. You don't want to produce a product that is inadequate due to your resistance to change.
• Control of requirements stability is important to overall success as one of the more critical mistakes that you can make is to assume that your requirements are stable while they are swinging back and forth.
• Work on the requirements closely with the customers, use prototyping techniques, lifecycle processes that give a lot of feedback to the customer.
• Provide cost and schedule estimate for every change - even small changes late in the project can have large cost.
• Move features to the next version - quick release cycles help a lot.
• Create a group of people responsible for change request processing - make sure process is not to bureaucratic.
• Implement software development method of triage - where only the most important changes get to be implemented.

• Productivity tools help with development work, however, remember that they usually never help as much as marketing department of the company that produces (sells) them.
• Remember that every new tool and every new technique requires learning time. During training tools use might decrease development speed instead of increasing it. Without training in the usage of the new software your team might not be able to use it efficiently, negating all the gain that the tool would have brought with it in terms of time savings.
• No tool or technique will provide dramatic improvements when used alone - don't get fuelled by empty claims of software vendors.
• Tools are great at helping with tasks that computers were designed to simplify - for example, they can eliminate need to repeat any aspect of development work. Good HTML development environment will provide closing tags to all open tags entered by the developer.
• Higher level programming languages trade speed for decreased detail control. If you don't have tight specifications and are able to satisfy your customer with standard application look then savings will be noticeable.
• You may consider creation of a special team of experienced developers responsible for new tool acquisition. This team will analyze and suggest new tools.
• All software that you going to buy should not only satisfy your current needs, but also your needs in the foreseeable future (not too far away future - only the one you can see from planning).
• You should by software from reputable vendor of good quality (version 3 and above show that the "baby bugs" are mostly eradicated and that the vendor will be less likely to cancel further tool development work).
• Total payoff from the usage of a tool should be counted against the area the tool acts in. For example, if you switched from C to Visual Basic you should expect most savings in coding, less in design, none in testing.
• Savings in effort needed due to the use of a tool don't linearly correspond to savings in schedule.
• CASE tools are in most cases (except where high amount of database work is involved) high end diagram creation tools.
• Object oriented programming is great for reusability of code, however, it doesn't offer any improvements as far as ease of use is concerned. Contrary to popular claims, OO is not more natural way to program (if it was so natural we would all be great OO programmers - everyone knows that is a false statement).

• The key to placing project under control is to go back to the basic ideas of software development.
• Don't rescue projects that are just having small problems. Through it might seem wise to try to cure the problem early on, before it develops into a full-grown disease. Rescue that is started to early will be seen in negative light by upper management, which will never see any problem with the project as it was. They will, however, see you, project manager as the one crying for help prematurely - whistle blower.
• When you want to regain control, don't shorten any development phases. If you do, you are loosing control over the project rather than gaining it (as you known less about what is going on).
• You need to be realistic as to what can be done, ask your team members what they can do. Developers will not commit to objectives that are out of their reach (they are too logical to do so).
• The following is a list of steps you should follow when you begin project rescue:
• Find out what is going on in the project - make a quick reckon of project accomplishments so far and its goals.
• Do anything in order to restore your teams morale and commitment to the project.
• Remember that one of the classic mistakes that you can do is to add people to the project when it is in need of help, sometimes this can help - but it needs to be very well planned operation.
• Make sure you eliminate as many classical development mistakes as possible.
• Your developers task completion should be evaluated using binary system, either they done their task 100% or not (anything less than 100%).
• Small milestones should be scheduled. Project and individual developer recalibration should be done on weekly basis.
• Make sure project requirements don't change - you don't want to chase shadows. If possible, remove as many features as possible from project specification.
• Remove broken parts of the code - re-write them if necessary. Your project's code should be of good quality. This will prevent your team from spinning its wheels while coping with masses of multiplying, never ending defects in the code.
• Be aware that projects that fail might be result of a political situation in your company, for example a power struggle. If this is the case - there is little hope to solve projects problems.