10 Software Process Management Best Practices
1. Define roles and tasks of team members: For productivity, roles of team members should be defined clearly. These roles may be project manager, team lead, developer, tester etc. Furthermore, authorizations and responsibilities of these roles should be defined very clearly. Task-assignment based development should also be applied for avoiding redundant efforts and chaos.
2. Define meeting types: Meetings are very important if we are talking about software process management and should be defined in detail (meeting participants, context, average duration etc.). Team members should also obey meeting rules. This will bring more productive meeting and development process, and will avoid losing time unnecessarily.
3. Define documentation strategy: Every single software process has a documentation strategy, even agile or extreme methods (backlogs, lessons learned info, bug items etc.). These documentation types should be defined clearly (document physical properties, standard sections, document update period, version numbering etc.) for consistency, understandability and more effective software production.
4. Define software quality metrics and measure them:
There are so many metric types (line of code, cyclomatic complexity etc.) in software world. According to the properties of your software type, some of these should be chosen to measure quality and growth of code. These info may be discussed periodically and production quality will be increased after assessments. 5. Perform issue/requirement tracking: Requirement management or issue tracking is one of the key points in software development. They determine the scope of software, also supports a traceability base for functional tests. Those issues/requirements are preferred to be saved and managed with useful tools which have more features than text editing.
6. Perform version controlling: Version controlling is also crutial in production. This should include code and other documents. It will support co-working on code, returning to older versions of code and will ease versioning and dependency management. Versioning strategy (version numbering,versioning periods etc.) should also be determined clearly to obtain consistency.
7. Perform testing: Testing is one of the main phases of software development. Unit testing must be performed for every type of software, except a few exceptions like some user interface code. Other testing types (system, user, integration etc.) should be defined clearly and applied consistently as defined. This will increase quality of production and decrease bugs.
8. Perform dependency management: As software projects grow, more external libraries (jar, dll, ...) or projects (external projects or internal company projects) are included. If those items are added to projects imprecisely, later updates or version changes will bring chaos and so much time consumption. Dependency management strategies and tools should be used for efficient productivity.
9. Perform code reviews frequently: Code review brings high quality code. First of all it enforces developer to produce better code, because it will be controlled by others. Besides, a junior developer will learn better coding quickly by corrections of senior developers. So, code review is a partial type of pair programming and it enhances productivity.
10. Save "lessons learned" info for your projects: Even if there are experienced staff in projects, there may be unforeseen events which may obstruct or retard development process. This can be a complex item configuration, error, production experience etc. Those happenings are highly preferred to be written in "lessons learned" documents and shared in public locations. This will avoid recurrence of time loss and provide more productive software process management.
10 Groups of Software Quality Factors That Should Be Remembered
Flexibility and Extensibility:
Flexibility is the ability of software to add/modify/remove functionality without damaging current system. Extensibility is the ability of software to add functionality without damaging system, so it may be thought as a subset of flexibility. Those functionality changes may occur acoording to changing requirements, or an obligation if development process is one of the iterative methods. Change is inevitable in software development and so, this is one of the most important properties of quality software.
Maintainability and Readability:
Maintainability is a little similar with flexibility but it focuses on modifications about error corrections and minor function modifications, not major functional extensibilities. It can be supported with useful interface definitions, documentations and also self-documenting code and/or code documentation. The more correct and useful documentation exists, the more maintainability can be performed.
Performance and Efficiency: Performance is mostly about response time of the software. This response time should be in acceptable intervals (e.g. max. a few seconds), and should not increase if transaction count increases. And also, resources are expensive. Efficiency must be supported with resource utilization. As an exaggerated example, ability of performing a simple function only by using a 32 processor machine or 1 TB disk space is not acceptable. Optimal source/performance ratio must be aimed.
Scalability:
A scalable system responds user actions in an acceptable amount of time, even if load increases. Of course more hardware may be added for handling increasing user transaction, but the architecture should not change while doing this. This is called vertical scalability. Ability of running on multiple, increasing count of machines is multiple processing. If the software can perform that type of processing, this is called horizontal scalability. A preffered scalable system should suit both of these methods.
Availability, Robustness, Fault Tolerance and Reliability:
A robust software should not lose its availabilty even in most failure states. Even if some components are broken down, it may continue running. Besides, even if whole application crashes, it may recover itself using backup hardware and data with fault tolerance approaches. There should always be B and even C, D .. plans. Reliability also stands for the integrity and consistency of the software even under high load conditions. So it is relevant with availability and scalability. An unreliable system is also unscalable.
Usability and Accessability:
User interfaces are the only visible parts of software according to the viewpoint of user. So, simplicity, taking less time to complete a job, fast learnability etc. are very important in this case. The most well known principle for this property is KISS (Keep It Simple Stupid). Simple is always the best. A usable software should also support different accessibility types of control for people with disabilities.
Platform Compatibility and Portability: A quality software should run on as much various platforms as it can. So, more people can make use of it. In different contexts we may mention different platforms, this may be OS platforms, browser types etc. And portability is about adapting software that can run on different platforms, for being more platform compatible. In this sense, portability is also related with flexibility.
Testability and Managability:
Quality software requires quality testing. Source code should be tested with the most coverage and with the most efficient testing methods. This can be performed by using encapsulation, interfaces, patterns, low coupling etc. techniques correctly. Besides testability, a qualified software should be manageable after deployment. It may be monitored for e.g. performance or data usage status, or may enable developer to configure system easily. Creating a successful logging system is another very important issue about managability.
Security:
Security is a very important issue on software development, especially for web or mobile based ones which may have millions of users with the ability of remote accessing to system. You should construct a security policy and apply it correctly by leaving no entry points. This may include authorization and authentication techniques, network attack protections, data encryption and so on. all possible types of security leaks should be considered, otherwise one day only one attack may crash your whole applicaion and whole company.
Functionality and Correctness:
Functionality (or correctness) is the conformity of the software with actual requirements and specifications. In fact this is the precendition attribute of an application, and maybe not a quality factor but we wanted to point that as the last quality factor, for taking attention: Quality factors are not meaningful when we are talking about unfunctional software. First, perform desired functionality and produce correct software, then apply quality factors on it. If you can perform both paralelly, it is the best.
Estimating Duration
It is very common for project managers (and others) to be asked to estimate the duration of a project or a large piece of work. You cannot provide an estimate of duration unless you also have an estimate of the effort hours. Even if you provide an initial estimate in terms of duration, you need to at least mentally understand the effort involved.
Estimates for effort are normally given in terms of hours. For instance, you might estimate a piece of work to be 500 effort hours. However, how long will this 500 hour piece of work take to complete? Now it becomes a little trickier. If a resource was working on the activity full-time, it might take 13 weeks+. If two people were working full-time, it might take seven weeks. If a person was working on the activity for 50% of the time, it might take a six months or more.
Calculating duration estimates is not as easy as it might sound. If everyone worked eight hours per day, and was absolutely, 100% productive for all that time, you could easily calculate the duration by taking the number of effort hours, divide by the number of resources, divided by the number of hours they work per day. For instance, if an activity was estimated at 80 hours, and you have one person assigned, and they work eight hours per day, the duration would be 10 days (80 effort hours / 1 person / 8 hours per day). Likewise, if four people were assigned, the duration would be (80 / 4 / 8) = 2.5 days.
However, those perfect circumstances are not indicative of how work is actually performed. Therefore, you can convert effort hours to duration for resource-constrained activities using the following process.
Agile Software Methodology
Agile is software development methodology. It is veryeffective where Client frequently changes his requirement. Since it has more iteration so you can assure a solutionthat meets clients requirement. More than one build deployement for a project. It involves more client interection and testing effort.
There are two methods by which this methodology can be implemented:-
1- Scrum
2- Extreme Progamming
Scrum: Each iteration would called a scrum which can be a 1-2 Months. In Scrum Client prioritise his requirements what he want first. If developer did not meets all the requirement which was being fixed for a particular scrum than rest of the development part would be transferred to the next scrum (would be delievered in the next build), means developer can't increase time decided for a scrum. Its fixed.
Extreme Programming (XP): Here iteration period would be less than in scrum , which is being 2-4 weeks.
Here developer prioritise what to do first on the basis of client requirement.
This duration which was being fixed for a iteration, can be increased if some development part is still pending. The build would deployed with having all the client needs. Thus iteration period is not fixed here it can be increased, but iteration should meets all the client's requirement in this build. More attension is required for testing in XP.
There are many flavours of Agile Development:
1- Agile Manifesto
2- (XP) Extreme Progamming
3- Scrum
4- Crystal
5- Context Driven Testing
6- Lean Development 7- (Rational) Unified Process
Agile methodology is a conceptual framework where software is devloped in iterations. Each iterations has Requirement analysis, planning, design, coding, testing and documentation.Characteristics :
In waterfall, development teams only have one chance to get each aspect of a project right. In an agile paradigm, every aspect of development — requirements, design, etc. — is continually revisited throughout the lifecycle. When a team stops and re-evaluates the direction of a project every two weeks,
there’s always time to steer it in another direction.
The results of this “inspect-and-adapt” approach to development greatly reduce both development costs and time to market. Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as “analysis paralysis” can’t really impede a team from making progress. And because a team’s work cycle is limited to two weeks, it gives stakeholders recurring opportunities to calibrate releases for success in the real world.
In essence, it could be said that the agile development methodology helps companies build the right product.
Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace. In the end, a
development agile methodology that preserves a product’s critical market relevance and ensures a team’s work doesn’t wind up on a shelf, never released, is an attractive option for stakeholders and developers alike.
Four steps for reducing project risk
Whether it's small or large, complex or simple, every project has risk. It's our job as managers to do our best to not only minimize the risk in our projects but to minimize it as soon as we can. In this article, you'll learn a simple four-step approach for doing just that.
Inventory
The first step to managing the risk of a project is to inventory the situation. That is, identify all of the risks that you think are possible in the project. The inventory should include all internal factors for the project such as resource changes, assumption failures, and sponsor availability. It should also include all external factors such as a change in company direction or a change of technology direction. Most of all, however, it should include the things that are new in the project. If the project is working with a new technology, is using a new development methodology, or even if there are new, relatively unknown team members, these need to be listed as potential risks to the project.
The purpose of the inventory phase isn't to classify the risk or identify its importance. That step happens later. The goal is to collect all the risks. If you mix in the process of evaluating the risk you’ll find that you won’t get a complete inventory of the potential risks for the project. Staying focused on capturing risks is essential to the process.
Evaluate
Once you have a complete list of potential risks, it’s time to evaluate them. Each risk should be evaluated based both on its probability and on the impact that it would cause if it happens. The loss of a key team member may have a low probability; however, the impact to the project can be great.
Some people struggle with the evaluation step because both of the numbers, percentage and impact, are guesses. They recognize that even subtle changes in the values for these numbers can have a huge impact on the total risk of the project. However, in general, the objective here isn’t to come up with a single number that represents each risk. The objective is to develop a framework for evaluating the various risks against one another. Although precision in the estimating process is useful it's not essential.
The other factor to evaluate when looking at a risk is its duration--how long that it can have a potential impact on the project. For instance, the loss of a subject matter expert early in the project is a risk because their input is still needed. However, later in the project they may not have much input and therefore aren't a risk if they leave.The risk of a functional analyst leaving is greatest in the initial phases of the project when they are intensively interacting with the customer. Later on in the project, the loss of the functional analyst has a smaller potential impact for the project.
In order to get a consistent number for all of the risks, multiply the probability which should be per interval of duration by the impact and finally multiply that by the duration. The resulting number is a single number, a risk quotient, which can be used to prioritize risks within the project. For instance, if the probability of the risk happening in a given week is 10%, the number of weeks the risk may happen is 10 weeks, and the impact is $1000, the overall risk is $1000. (.10*10*1000 = 1000)
Prioritize
Now that you have a single risk quotient for the various risks, it's possible to prioritize the risks for the project. It can give you a clear vision of what the risks are and which ones you'll ultimately need to be concerned about. This is also a part of the process that typically helps validate the estimates made above. For instance, if your greatest risk is personnel turnover (as it usually is) you may want to more objectively evaluate the probability. If the average person stays at your organization for three years you can assume a probability of them leaving in a given week is 1/156 (3x52 weeks/year) which is a 0.00641 percent chance.
Control and mitigate
Once the risks are prioritized you can go through the list and identify which risks are controllable, which risks are things that can be mitigated, and which risks must be accepted. For instance, the risk of loosing key personnel can be mitigated by providing completion bonuses or even just monitoring their happiness more closely. Technical risks can be controlled by moving them forward in the project so that they are proven out nearly immediately.
In general, the fastest way to reduce the overall risk quotient for a project is to tackle the controllable risks early in the project. The more quickly that you are able to validate the risk associated with an item the more quickly the risk is no longer a risk (so its probability can be zeroed out.) Focusing on controllable risks won't completely eliminate risk but it will quickly cut it down.
The next step is to develop mitigation strategies for those risks that can’t be controlled. Completion bonuses are a routine way that organizations which are closing down operations mitigate the risk that the people participating will leave before the project is ready to let them go.
Not every mitigation strategy needs to involve money. Simply getting a verbal, personal commitment to finish the project is often enough to further reduce the probability that a person will leave during the project. Most people value their own sense of self worth and they believe that their ability to meet their personal commitments is a part of the admirable part of their self.
Following site contains project document templates
http://www.projectmanagementdocs.com/project-documents.html
Note: Click on the headings (in blue color)mentioned below to open the related templates
Project Document Templates
Activity Attributes
Bad surprises can be painful. Know exactly what you’re getting into, before you get into it. Be sure to protect your project from less than pleasant surprises by planning and documenting each of your activities before hand. Use our activity attribute template to develop your own easy-to-read, and understand, activity attributes document. Many project management systems will allow you to integrate activity attributes directly into the system.
Activity Cost Estimates
Just because it looks like a million bucks doesn’t mean you have to spend that much. Know exactly what your costs will be before they leave you broke. A well-prepared manager is a good manager, and a good manager knows the true costs of their project. Use our activity cost estimate template, and discover a sound framework to determine your project’s actual cost.
Activity List
Remember, the details always determine the outcome. Use an itemized activities list to keep the finer points of your project as sharp as possible. Plan each activity of your project, and get better results. Use the activity list to fill-in short descriptions of each process, and be sure to include whom they’re assigned to. It makes projects much easier to execute when everyone knows their specific responsibilities.
Assumption Log
No matter the project, you’re going to need to make some educated guesses. Be sure you log these assumptions as they’re made, and validate them all. If you’re not paying attention, you’ll never know which ones are right – and even more dangerously – which are wrong.
Basis of Estimate
It’s of prime importance that you do all of your financial planning before ever starting a project. It allows for a more streamlined process, and more importantly, helps you avoid going over budget. Make sure you’re the one who’s enjoying your profits.
Change Log
There’s a million ways to change a project. Be sure to log each change you make, so you can be sure that your project is always looking its best. In a world of endless choices, it’s important that you only make the best ones. Be sure to log all project changes, and validate each and every one of them. It helps keep your processes organized, and failing to do doing so puts you and your organization at risk of making critical mistakes.
Change Request
Unplanned project changes are necessary in every project. However, some changes are great, but others aren’t. By formally submitting a change request for each change that comes up in a project, you can make them much more manageable. Filter out the bad ideas, embrace the good ones, but keep all of them organized.
Duration Estimate
You don't need to be a rocket scientist to calculate durations. Ensure the success of your project by having a planned methodology for estimating and cataloging durations. Accurate duration estimating is important for developing an accurate project schedule and finishing a project on time.
Issue Log
Don't just sound-off about your issues! Log and validate, then act on the valid issues. Issues will arise during your project. Maintain a written issue log to document and monitor all issues. Be sure issues are resolved by their target date, or escalated if necessary. Don't let unresolved issues bring your project down.
Meeting Agenda
A well run meeting starts with a well planned meeting agenda. Have you ever been frustrated because a meeting agenda was sent out 30 minutes before the meeting was scheduled to start? Or not provided an agenda until you arrive at the meeting? It's difficult to know what to expect during a meeting and to prepare for the meeting if you don't have an agenda well in advance of the meeting. Typically a meeting agenda should be distributed one week prior to the meeting - or at least a minimum of two days prior to the meeting. Meeting Minutes
A well executed meeting ends with prompt and clearly documented Meeting Minutes. A skilled and successful Project Manager always has meeting minutes prepared and distributed within 24 hours of having a meeting. Project meeting minutes not only summarize what was discussed and agreed upon during the meeting but also includes a list of action items. It is important that the action items are documented and distributed quickly so the assignees have enough time to follow up on their action items or ask for clarification.
Milestone List
As a significant point or event in your project, all project milestones should be listed and tracked. Milestones are a good means to determine if your project is on schedule and a useful tool for reporting to management. Performance Report
As a project manager, it's important to show your manager just how well and streamlined all of the processes under your watch are running. Let the "higher ups" know that everything is okay, and that you’re performing at your best, with our performance report template.
Project Funding Requirements
Knowing exactly what your funding requirements will be, before you even get started, is extremely important to the overall success of a project. Use our project funding requirements template to plan ahead and avoid the often-dangerous last minute scramble for additional funding.
Proposal
Proposal Writing Posing More Questions than Answers? We’ve got the Simple Solution. This easy to use proposal template provides an excellent starting point to write the small proposals that are usually required before performing work on a specific part of a project.
Quality Checklist
Quality doesn’t just happen, it’s a product of proper project management. Use a quality checklist to ensure quality is planned into your project. A lack of quality control makes it impossible to guarantee quality in your projects. By implementing a Quality Checklist for all your projects, you can "check" each item off as you develop your project plan. Rest easy knowing that you have all of your bases covered!
Quality Metrics
It's impossible to recognize quality if you don’t know what it is in the first place. Define your Quality Metrics before starting your project. Quality Metrics help you translate your clients' needs into measurable goals. It's critical that you define a set of quality metrics during your project’s planning phase, so that you and your team know exactly what you need to get done.
Request for Proposal
This Request for Proposal template (RFP template) is a good starting point for developing your project specific RFP. It contains necessary key elements and helpful insight into the Request for Proposal.
Statement of Work
A Statement of Work (SOW) is a very powerful project management tool. Putting a bit of time into creating a detailed SOW will help to ensure that work is being performed according to your specifications and expectations. By clearly defining the work to be done it is more likely that the work is completed according to the project plan.
Also look at the following site:
http://www.mhhe.com/engcs/compsci/pressman/graphics/Pressman5sepa/common/cs2/rmmm.pdf
1. Define roles and tasks of team members: For productivity, roles of team members should be defined clearly. These roles may be project manager, team lead, developer, tester etc. Furthermore, authorizations and responsibilities of these roles should be defined very clearly. Task-assignment based development should also be applied for avoiding redundant efforts and chaos.
2. Define meeting types: Meetings are very important if we are talking about software process management and should be defined in detail (meeting participants, context, average duration etc.). Team members should also obey meeting rules. This will bring more productive meeting and development process, and will avoid losing time unnecessarily.
3. Define documentation strategy: Every single software process has a documentation strategy, even agile or extreme methods (backlogs, lessons learned info, bug items etc.). These documentation types should be defined clearly (document physical properties, standard sections, document update period, version numbering etc.) for consistency, understandability and more effective software production.
4. Define software quality metrics and measure them:
There are so many metric types (line of code, cyclomatic complexity etc.) in software world. According to the properties of your software type, some of these should be chosen to measure quality and growth of code. These info may be discussed periodically and production quality will be increased after assessments. 5. Perform issue/requirement tracking: Requirement management or issue tracking is one of the key points in software development. They determine the scope of software, also supports a traceability base for functional tests. Those issues/requirements are preferred to be saved and managed with useful tools which have more features than text editing.
6. Perform version controlling: Version controlling is also crutial in production. This should include code and other documents. It will support co-working on code, returning to older versions of code and will ease versioning and dependency management. Versioning strategy (version numbering,versioning periods etc.) should also be determined clearly to obtain consistency.
7. Perform testing: Testing is one of the main phases of software development. Unit testing must be performed for every type of software, except a few exceptions like some user interface code. Other testing types (system, user, integration etc.) should be defined clearly and applied consistently as defined. This will increase quality of production and decrease bugs.
8. Perform dependency management: As software projects grow, more external libraries (jar, dll, ...) or projects (external projects or internal company projects) are included. If those items are added to projects imprecisely, later updates or version changes will bring chaos and so much time consumption. Dependency management strategies and tools should be used for efficient productivity.
9. Perform code reviews frequently: Code review brings high quality code. First of all it enforces developer to produce better code, because it will be controlled by others. Besides, a junior developer will learn better coding quickly by corrections of senior developers. So, code review is a partial type of pair programming and it enhances productivity.
10. Save "lessons learned" info for your projects: Even if there are experienced staff in projects, there may be unforeseen events which may obstruct or retard development process. This can be a complex item configuration, error, production experience etc. Those happenings are highly preferred to be written in "lessons learned" documents and shared in public locations. This will avoid recurrence of time loss and provide more productive software process management.
10 Groups of Software Quality Factors That Should Be Remembered
Flexibility and Extensibility:
Flexibility is the ability of software to add/modify/remove functionality without damaging current system. Extensibility is the ability of software to add functionality without damaging system, so it may be thought as a subset of flexibility. Those functionality changes may occur acoording to changing requirements, or an obligation if development process is one of the iterative methods. Change is inevitable in software development and so, this is one of the most important properties of quality software.
Maintainability and Readability:
Maintainability is a little similar with flexibility but it focuses on modifications about error corrections and minor function modifications, not major functional extensibilities. It can be supported with useful interface definitions, documentations and also self-documenting code and/or code documentation. The more correct and useful documentation exists, the more maintainability can be performed.
Performance and Efficiency: Performance is mostly about response time of the software. This response time should be in acceptable intervals (e.g. max. a few seconds), and should not increase if transaction count increases. And also, resources are expensive. Efficiency must be supported with resource utilization. As an exaggerated example, ability of performing a simple function only by using a 32 processor machine or 1 TB disk space is not acceptable. Optimal source/performance ratio must be aimed.
Scalability:
A scalable system responds user actions in an acceptable amount of time, even if load increases. Of course more hardware may be added for handling increasing user transaction, but the architecture should not change while doing this. This is called vertical scalability. Ability of running on multiple, increasing count of machines is multiple processing. If the software can perform that type of processing, this is called horizontal scalability. A preffered scalable system should suit both of these methods.
Availability, Robustness, Fault Tolerance and Reliability:
A robust software should not lose its availabilty even in most failure states. Even if some components are broken down, it may continue running. Besides, even if whole application crashes, it may recover itself using backup hardware and data with fault tolerance approaches. There should always be B and even C, D .. plans. Reliability also stands for the integrity and consistency of the software even under high load conditions. So it is relevant with availability and scalability. An unreliable system is also unscalable.
Usability and Accessability:
User interfaces are the only visible parts of software according to the viewpoint of user. So, simplicity, taking less time to complete a job, fast learnability etc. are very important in this case. The most well known principle for this property is KISS (Keep It Simple Stupid). Simple is always the best. A usable software should also support different accessibility types of control for people with disabilities.
Platform Compatibility and Portability: A quality software should run on as much various platforms as it can. So, more people can make use of it. In different contexts we may mention different platforms, this may be OS platforms, browser types etc. And portability is about adapting software that can run on different platforms, for being more platform compatible. In this sense, portability is also related with flexibility.
Testability and Managability:
Quality software requires quality testing. Source code should be tested with the most coverage and with the most efficient testing methods. This can be performed by using encapsulation, interfaces, patterns, low coupling etc. techniques correctly. Besides testability, a qualified software should be manageable after deployment. It may be monitored for e.g. performance or data usage status, or may enable developer to configure system easily. Creating a successful logging system is another very important issue about managability.
Security:
Security is a very important issue on software development, especially for web or mobile based ones which may have millions of users with the ability of remote accessing to system. You should construct a security policy and apply it correctly by leaving no entry points. This may include authorization and authentication techniques, network attack protections, data encryption and so on. all possible types of security leaks should be considered, otherwise one day only one attack may crash your whole applicaion and whole company.
Functionality and Correctness:
Functionality (or correctness) is the conformity of the software with actual requirements and specifications. In fact this is the precendition attribute of an application, and maybe not a quality factor but we wanted to point that as the last quality factor, for taking attention: Quality factors are not meaningful when we are talking about unfunctional software. First, perform desired functionality and produce correct software, then apply quality factors on it. If you can perform both paralelly, it is the best.
Estimating Duration
It is very common for project managers (and others) to be asked to estimate the duration of a project or a large piece of work. You cannot provide an estimate of duration unless you also have an estimate of the effort hours. Even if you provide an initial estimate in terms of duration, you need to at least mentally understand the effort involved.
Estimates for effort are normally given in terms of hours. For instance, you might estimate a piece of work to be 500 effort hours. However, how long will this 500 hour piece of work take to complete? Now it becomes a little trickier. If a resource was working on the activity full-time, it might take 13 weeks+. If two people were working full-time, it might take seven weeks. If a person was working on the activity for 50% of the time, it might take a six months or more.
Calculating duration estimates is not as easy as it might sound. If everyone worked eight hours per day, and was absolutely, 100% productive for all that time, you could easily calculate the duration by taking the number of effort hours, divide by the number of resources, divided by the number of hours they work per day. For instance, if an activity was estimated at 80 hours, and you have one person assigned, and they work eight hours per day, the duration would be 10 days (80 effort hours / 1 person / 8 hours per day). Likewise, if four people were assigned, the duration would be (80 / 4 / 8) = 2.5 days.
However, those perfect circumstances are not indicative of how work is actually performed. Therefore, you can convert effort hours to duration for resource-constrained activities using the following process.
- Estimate the productive hours per day. Normally the first step is to determine how many productive hours of work you can count on each person working over time. In other words, if an activity is scheduled to take 40 effort hours, it is unlikely that it can be completed in a calendar week, without overtime. Using a factor of 6.5 productive hours per day will help you take into account socializing, morning ramp-up time, walking to meetings, going to the bathroom etc.
- Determine how many resources will be applied to each activity. Obviously two resources may be able to complete an activity faster than one person, but it may not be twice as fast. Similarly, a third person may allow the task to be completed sooner, but not in one-third the time. (At some point, adding resources will not make the activity complete any sooner, and in fact, may make it go longer.)
- Factor in available workdays, holidays, vacations, training, etc. This time was not included in the productivity factor above, since this non-project time can be scheduled and accounted for in advance. For instance, on a three-month project, each team member may be out for two holidays, while one may also have ten days of vacation.
- Take into account any resources that are not full time. If you have a resource 50% of the time, it will take them at least twice as long to do any individual activity. If you have an activity that has an estimated effort of 40 hours, and you assign a resource that is only available for 25% of their time, the resulting duration will be at least four weeks - probably more.
- Factor in multi-tasking productivity loss for part-time resources. You can do this if you have a sense for any additional assignments team members will be working on. (If you do not have this detailed information, you cannot easily factor in multi-tasking productivity loss, although you may be able to deduct a generic average.) If one person is working on multiple projects, or perhaps a combination of projects and support, a further reduction in productivity needs to be taken into account. This reflects the fact that if a person is shared on two or more unrelated efforts, it takes time to stop one and start up another. If a person is on two projects for 20 hours each week, they are going to lose additional productive time switching back and forth. If the person is on two projects, this might result in a 10% loss of productivity on both projects. If they are on three (or more) each effort could take up to a 20% productivity hit. For example, if a person was split between three projects for 24, 10 and 6 hours, the project managers should initially factor in closer to 20, 8 and 4 hours of productive time per week. Further, since there are three projects involved and there will be stopping and starting time, the re-factored productive time might be closer to 19, 7 and 3 hours respectively per project.
Agile Software Methodology
Agile is software development methodology. It is veryeffective where Client frequently changes his requirement. Since it has more iteration so you can assure a solutionthat meets clients requirement. More than one build deployement for a project. It involves more client interection and testing effort.
There are two methods by which this methodology can be implemented:-
1- Scrum
2- Extreme Progamming
Scrum: Each iteration would called a scrum which can be a 1-2 Months. In Scrum Client prioritise his requirements what he want first. If developer did not meets all the requirement which was being fixed for a particular scrum than rest of the development part would be transferred to the next scrum (would be delievered in the next build), means developer can't increase time decided for a scrum. Its fixed.
Extreme Programming (XP): Here iteration period would be less than in scrum , which is being 2-4 weeks.
Here developer prioritise what to do first on the basis of client requirement.
This duration which was being fixed for a iteration, can be increased if some development part is still pending. The build would deployed with having all the client needs. Thus iteration period is not fixed here it can be increased, but iteration should meets all the client's requirement in this build. More attension is required for testing in XP.
There are many flavours of Agile Development:
1- Agile Manifesto
2- (XP) Extreme Progamming
3- Scrum
4- Crystal
5- Context Driven Testing
6- Lean Development 7- (Rational) Unified Process
Agile methodology is a conceptual framework where software is devloped in iterations. Each iterations has Requirement analysis, planning, design, coding, testing and documentation.Characteristics :
- - Many builds are delivered in the iteration process
- - Accepts change of requirement at any stage
- - Requires close communication between business,
- - Reduced risk and time to develop
- - Less documentation work compared to other methodologies
- - Requires continuous testing
Agile development methodology attempts to provide many opportunities to assess the direction of a project throughout the development lifecycle.
In waterfall, development teams only have one chance to get each aspect of a project right. In an agile paradigm, every aspect of development — requirements, design, etc. — is continually revisited throughout the lifecycle. When a team stops and re-evaluates the direction of a project every two weeks,
there’s always time to steer it in another direction.
The results of this “inspect-and-adapt” approach to development greatly reduce both development costs and time to market. Because teams can gather requirements at the same time they’re gathering requirements, the phenomenon known as “analysis paralysis” can’t really impede a team from making progress. And because a team’s work cycle is limited to two weeks, it gives stakeholders recurring opportunities to calibrate releases for success in the real world.
In essence, it could be said that the agile development methodology helps companies build the right product.
Instead of committing to market a piece of software that hasn’t even been written yet, agile empowers teams to optimize their release as it’s developed, to be as competitive as possible in the marketplace. In the end, a
development agile methodology that preserves a product’s critical market relevance and ensures a team’s work doesn’t wind up on a shelf, never released, is an attractive option for stakeholders and developers alike.
Four steps for reducing project risk
Whether it's small or large, complex or simple, every project has risk. It's our job as managers to do our best to not only minimize the risk in our projects but to minimize it as soon as we can. In this article, you'll learn a simple four-step approach for doing just that.
Inventory
The first step to managing the risk of a project is to inventory the situation. That is, identify all of the risks that you think are possible in the project. The inventory should include all internal factors for the project such as resource changes, assumption failures, and sponsor availability. It should also include all external factors such as a change in company direction or a change of technology direction. Most of all, however, it should include the things that are new in the project. If the project is working with a new technology, is using a new development methodology, or even if there are new, relatively unknown team members, these need to be listed as potential risks to the project.
The purpose of the inventory phase isn't to classify the risk or identify its importance. That step happens later. The goal is to collect all the risks. If you mix in the process of evaluating the risk you’ll find that you won’t get a complete inventory of the potential risks for the project. Staying focused on capturing risks is essential to the process.
Evaluate
Once you have a complete list of potential risks, it’s time to evaluate them. Each risk should be evaluated based both on its probability and on the impact that it would cause if it happens. The loss of a key team member may have a low probability; however, the impact to the project can be great.
Some people struggle with the evaluation step because both of the numbers, percentage and impact, are guesses. They recognize that even subtle changes in the values for these numbers can have a huge impact on the total risk of the project. However, in general, the objective here isn’t to come up with a single number that represents each risk. The objective is to develop a framework for evaluating the various risks against one another. Although precision in the estimating process is useful it's not essential.
The other factor to evaluate when looking at a risk is its duration--how long that it can have a potential impact on the project. For instance, the loss of a subject matter expert early in the project is a risk because their input is still needed. However, later in the project they may not have much input and therefore aren't a risk if they leave.The risk of a functional analyst leaving is greatest in the initial phases of the project when they are intensively interacting with the customer. Later on in the project, the loss of the functional analyst has a smaller potential impact for the project.
In order to get a consistent number for all of the risks, multiply the probability which should be per interval of duration by the impact and finally multiply that by the duration. The resulting number is a single number, a risk quotient, which can be used to prioritize risks within the project. For instance, if the probability of the risk happening in a given week is 10%, the number of weeks the risk may happen is 10 weeks, and the impact is $1000, the overall risk is $1000. (.10*10*1000 = 1000)
Prioritize
Now that you have a single risk quotient for the various risks, it's possible to prioritize the risks for the project. It can give you a clear vision of what the risks are and which ones you'll ultimately need to be concerned about. This is also a part of the process that typically helps validate the estimates made above. For instance, if your greatest risk is personnel turnover (as it usually is) you may want to more objectively evaluate the probability. If the average person stays at your organization for three years you can assume a probability of them leaving in a given week is 1/156 (3x52 weeks/year) which is a 0.00641 percent chance.
Control and mitigate
Once the risks are prioritized you can go through the list and identify which risks are controllable, which risks are things that can be mitigated, and which risks must be accepted. For instance, the risk of loosing key personnel can be mitigated by providing completion bonuses or even just monitoring their happiness more closely. Technical risks can be controlled by moving them forward in the project so that they are proven out nearly immediately.
In general, the fastest way to reduce the overall risk quotient for a project is to tackle the controllable risks early in the project. The more quickly that you are able to validate the risk associated with an item the more quickly the risk is no longer a risk (so its probability can be zeroed out.) Focusing on controllable risks won't completely eliminate risk but it will quickly cut it down.
The next step is to develop mitigation strategies for those risks that can’t be controlled. Completion bonuses are a routine way that organizations which are closing down operations mitigate the risk that the people participating will leave before the project is ready to let them go.
Not every mitigation strategy needs to involve money. Simply getting a verbal, personal commitment to finish the project is often enough to further reduce the probability that a person will leave during the project. Most people value their own sense of self worth and they believe that their ability to meet their personal commitments is a part of the admirable part of their self.
Following site contains project document templates
http://www.projectmanagementdocs.com/project-documents.html
Note: Click on the headings (in blue color)mentioned below to open the related templates
Project Document Templates
Activity Attributes
Bad surprises can be painful. Know exactly what you’re getting into, before you get into it. Be sure to protect your project from less than pleasant surprises by planning and documenting each of your activities before hand. Use our activity attribute template to develop your own easy-to-read, and understand, activity attributes document. Many project management systems will allow you to integrate activity attributes directly into the system.
Activity Cost Estimates
Just because it looks like a million bucks doesn’t mean you have to spend that much. Know exactly what your costs will be before they leave you broke. A well-prepared manager is a good manager, and a good manager knows the true costs of their project. Use our activity cost estimate template, and discover a sound framework to determine your project’s actual cost.
Activity List
Remember, the details always determine the outcome. Use an itemized activities list to keep the finer points of your project as sharp as possible. Plan each activity of your project, and get better results. Use the activity list to fill-in short descriptions of each process, and be sure to include whom they’re assigned to. It makes projects much easier to execute when everyone knows their specific responsibilities.
Assumption Log
No matter the project, you’re going to need to make some educated guesses. Be sure you log these assumptions as they’re made, and validate them all. If you’re not paying attention, you’ll never know which ones are right – and even more dangerously – which are wrong.
Basis of Estimate
It’s of prime importance that you do all of your financial planning before ever starting a project. It allows for a more streamlined process, and more importantly, helps you avoid going over budget. Make sure you’re the one who’s enjoying your profits.
Change Log
There’s a million ways to change a project. Be sure to log each change you make, so you can be sure that your project is always looking its best. In a world of endless choices, it’s important that you only make the best ones. Be sure to log all project changes, and validate each and every one of them. It helps keep your processes organized, and failing to do doing so puts you and your organization at risk of making critical mistakes.
Change Request
Unplanned project changes are necessary in every project. However, some changes are great, but others aren’t. By formally submitting a change request for each change that comes up in a project, you can make them much more manageable. Filter out the bad ideas, embrace the good ones, but keep all of them organized.
Duration Estimate
You don't need to be a rocket scientist to calculate durations. Ensure the success of your project by having a planned methodology for estimating and cataloging durations. Accurate duration estimating is important for developing an accurate project schedule and finishing a project on time.
Issue Log
Don't just sound-off about your issues! Log and validate, then act on the valid issues. Issues will arise during your project. Maintain a written issue log to document and monitor all issues. Be sure issues are resolved by their target date, or escalated if necessary. Don't let unresolved issues bring your project down.
Meeting Agenda
A well run meeting starts with a well planned meeting agenda. Have you ever been frustrated because a meeting agenda was sent out 30 minutes before the meeting was scheduled to start? Or not provided an agenda until you arrive at the meeting? It's difficult to know what to expect during a meeting and to prepare for the meeting if you don't have an agenda well in advance of the meeting. Typically a meeting agenda should be distributed one week prior to the meeting - or at least a minimum of two days prior to the meeting. Meeting Minutes
A well executed meeting ends with prompt and clearly documented Meeting Minutes. A skilled and successful Project Manager always has meeting minutes prepared and distributed within 24 hours of having a meeting. Project meeting minutes not only summarize what was discussed and agreed upon during the meeting but also includes a list of action items. It is important that the action items are documented and distributed quickly so the assignees have enough time to follow up on their action items or ask for clarification.
Milestone List
As a significant point or event in your project, all project milestones should be listed and tracked. Milestones are a good means to determine if your project is on schedule and a useful tool for reporting to management. Performance Report
As a project manager, it's important to show your manager just how well and streamlined all of the processes under your watch are running. Let the "higher ups" know that everything is okay, and that you’re performing at your best, with our performance report template.
Project Funding Requirements
Knowing exactly what your funding requirements will be, before you even get started, is extremely important to the overall success of a project. Use our project funding requirements template to plan ahead and avoid the often-dangerous last minute scramble for additional funding.
Proposal
Proposal Writing Posing More Questions than Answers? We’ve got the Simple Solution. This easy to use proposal template provides an excellent starting point to write the small proposals that are usually required before performing work on a specific part of a project.
Quality Checklist
Quality doesn’t just happen, it’s a product of proper project management. Use a quality checklist to ensure quality is planned into your project. A lack of quality control makes it impossible to guarantee quality in your projects. By implementing a Quality Checklist for all your projects, you can "check" each item off as you develop your project plan. Rest easy knowing that you have all of your bases covered!
Quality Metrics
It's impossible to recognize quality if you don’t know what it is in the first place. Define your Quality Metrics before starting your project. Quality Metrics help you translate your clients' needs into measurable goals. It's critical that you define a set of quality metrics during your project’s planning phase, so that you and your team know exactly what you need to get done.
Request for Proposal
This Request for Proposal template (RFP template) is a good starting point for developing your project specific RFP. It contains necessary key elements and helpful insight into the Request for Proposal.
Statement of Work
A Statement of Work (SOW) is a very powerful project management tool. Putting a bit of time into creating a detailed SOW will help to ensure that work is being performed according to your specifications and expectations. By clearly defining the work to be done it is more likely that the work is completed according to the project plan.
Also look at the following site:
http://www.mhhe.com/engcs/compsci/pressman/graphics/Pressman5sepa/common/cs2/rmmm.pdf