Radiant info school Project Management
Project Management Life Cycle
Managing your digital media project is one of the most important and often overlooked aspects of the development process. You will find that effort you put into planning, scheduling, and organizing your project will pay off enormously. Here we'll outline some proven techniques for planning, scheduling, and completing your project. A project has five phases. Here's a brief summary of each:
. Initiation Articulate your vision for the project, establish goals, assemble your team, and define expectations and the scope of your project. Develop a Business Case Undertake a Feasibility Study Establish the Project Charter
It will help you to define the scope of your project.
Writing the Project Charter is typically one of the most challenging steps in the Project Life Cycle, as it defines the parameters within which the project must be delivered.
It sets out the project vision, objectives, scope and implementation, thereby giving the team clear boundaries within which the project must be delivered.
Appoint the Project Team Set up the Project Office Perform Phase Review
Radiant info school Project Management
. Planning Refine the scope, identify specific tasks and activities to be completed, and develop a schedule and budget.
Create a Project Plan Create a Resource Plan Create a Financial Plan Create a Quality Plan Create a Risk Plan Create an Acceptance Plan Create a Communications Plan Create a Procurement Plan Contract the Suppliers Define the Tender Process Issue a Statement of Work Issue a Request for Information Issue a Request for Proposal Create Supplier Contract Perform Phase Review
execution Build Deliverables Monitor and Control Perform Time Management Perform Cost Management Perform Quality Management Perform Change Management This process helps you to manage all requests for change within your project. By putting this change process in place, you'll easily be able to monitor and control the amount of change that takes place.Within the Change Management Process, each of the key steps for managing change are included. It also tells you how to implement control change, through change approvals and reviews
Perform Risk Management Perform Issue Management Perform Procurement Management Perform Acceptance Management Perform Communications Management
Controlling Monitor changes to the project, make corrections, adjust your schedule to respond to problems, or adjust your expectations and goals
Radiant info school Project Management
CLOSURE Perform Project Closure Review Project Completion
PROJECT LIFE CYLCE
Stages might have included:
• Feasibility investigation – producing business case
Feasibility studies aim to objectively and rationally uncover the strengths and weaknesses of the existing business or proposed venture, opportunities and threats as presented by theenvironment, the resources required to carry through, and ultimately the prospects forsuccess.
A feasibility study is a preliminary, low-cost, high-level assessment to determine whether it would be practicable, desirable and worthwhile for an organization to pursue change or innovation through one or more projects. Starting a significant project without any form of pre-project study is akin to teaching firearms safety with a “Fire! Aim! Ready?” approach. In project work, such an approach can create potential for risks to be overlooked, needs and outcomes mismatched, eventual costs to become unacceptably high and for key dates to be missed.
Operational Evaluation
This evaluation is to examine how closely any proposed solution will meet operational requirements, so work done by the stakeholders and study team to define these at the start of the study will provide the yardstick against which every proposed solution can be measured. Prioritise each requirement into „Must-Do,‟ „Ought to Do‟ and „Nice to Do‟ categories before the analysis starts. As soon as a potential solution fails an operational „Must Do,‟ or looks to have unacceptable operational risks, set it aside with brief justification and move on.
Technical Evaluation
Here you need to examine some, perhaps all, of whether you have, or can acquire, the technical skills, capabilities and resources to design, develop, test, install, repair, maintain and modify the Radiant info school Project Management
solution and confirm that it will fit with existing and any planned technology. The criteria applied in this section will naturally differ when evaluating self-build versus procured and packaged versus bespoke solutions. The yardstick to use is a high level technical specification for the required solution, again developed between the study team and the organization‟s technical specialists. Eliminate any proposal that misses „must-have‟ technical requirements or appears to have unacceptable technical risk.
Economic / Financial Evaluation
Can the organization afford to build or procure, install and operate this solution? If one solution costs more than another to put in place, but less to operate, which is the better financial deal? If cost saving is a requirement (and where isn‟t it these days?) how quickly will the proposed solutions accrue these savings? How long is the payback period likely to be? What is the predicted rate of return on the organization‟s investment? For change and innovation that is mandatory, concentrate on investment costs and running cosT
Business case
A Business Case document is used whenever the expenditure on a project has to be justified. Completing a Business Case document is usually the first step in the Project Life Cycle. Once the Business Case document has been completed, it is presented to a Sponsor for approval. The Business Case is referred to frequently during the project, to determine whether it is currently on track. And at the end of the project, success is measured against the ability to meet the objectives defined in the Business Case. So the completion of a Business Case is critical to the success of the project.
By creating a convincing Business Case, you can document the return on investment for your solution, thereby creating a compelling Business Case for approval by your sponsor. It will help you identify the detailed benefits and costs of your solution, giving your sponsor confidence that the solution recommended is the most viable solution available. This will help you to gain approval of the business case and secure the funding you need, to get started.
By using the Business Case document, you can:
Research the business problem or opportunity Identify the alternative solutions available Quantify the benefits and costs of each solution Recommend a preferred solution to your sponsor Identify any risks and issues with implementation Present the solution for funding approval
The business case for the project is maintained as long as the development and operational costs of the application to be delivered do no exceed the value of the benefits of the project. Increased costs, reduced functionality, and deferred delivery could all have an impact on this business case Radiant info school Project Management
(That follows requirements elicitation) – There could be a variety of Products if something like SSADM has been used In order to ensure that the system specifications properly meet customer expectations we need to follow a solid requirement analysis process. Requirement analysis is critical to the success of a development project. It takes into account all the tasks that determine the needs for the project.
• System design/architecture design (which is at a higher level than software design)
Systems design is the process of defining the architecture, components, modules, interfaces, and data for a system to satisfy specified requirements
• Build/test – producing unit-tested software components
• Integration – producing an operable integrated system
• Acceptance – producing possible modifications, but eventually a sign-off
• Installation – resulting in an installed operational system
Bespoke vs. off-the-shelf software
Whether to buy tailored software solutions or off-the-shelf software packages is common dilemma. Marc Bray, marketing director of international software applications company, Logsys, examines the pros, cons and cost implications of both.
Growing companies are investing an increasing amount in IT systems to automate and simplify business processes. This means the market for such systems is vast, with imagination and budget the only boundaries.
As companies look to automate different business functions the question of bespoke or off-the-shelf is usually raised sooner rather than later.
Whether relying on an in-house IT team or outsourcing the work to a specialist company, the decision to purchase a ready made solution or to have software specifically developed raises a number of issues that must be considered.
The beauty of bespoke systems is that they are tailored to the exact requirements of the company allowing the software to fully integrate, helping to meet legislation or key business objectives.
Scalability is also a positive factor, with bespoke systems able to accommodate business growth and contract with any necessary downsizing. The system should evolve with the company to provide an ongoing perfect fit. Radiant info school Project Management
This is possible because bespoke systems are designed with the long term IT plans of a company in mind. Software of this type ensures that the company can move forward instead of just automating what it already does, resulting in it being stuck in the same rut.
In an ideal world every company would have bespoke software were it not for three important preventative factors:
Firstly, the cost of bespoke software can be much higher than off-the-shelf solutions. Individually crafted software often needs teams comprising of dozens of people each bringing particular skills such as analysts, programmers, hardware and software specialists and technical writers.
The time and manpower needed to create and maintain a bespoke system quickly adds up. However, bespoke software successfully developed can potentially be sold on, becoming an extra source of revenue for the company.
Secondly bespoke software can only match the requirements of the customer to the extent that the customer can define them and the developer can understand them. If the customer does not have a clear strategic plan for the business operations, long term IT plans that support the business requirement are difficult to determine.
The finished product is unlikely to have the capacity to evolve with the company, with errors and misunderstandings at the early stages of development leading to spiralling costs and delayed delivery.
Thirdly, the issue of compatibility can cause problems. If the software is not compatible with the existing systems, operational difficulties are likely to arise.
Legacy systems may not have been designed with integration in mind and therefore the ability to transfer data between systems may have a major impact on the inter-operation of systems.
Similarly if the software is not compatible with the systems of others, customers and suppliers for example, it may cause problems to the overall functioning of the business.
Generally speaking, off-the-shelf systems are produced to meet the perceived needs of a particular market or sector. They have, in effect, a one size fits all set of generic features and, for more complex applications, customization facilities.
As a rule, they are easy to install and easy to use. It is important to remember that off-the-shelf solutions are bred from the best components of various software systems, often beginning life as a bespoke package designed for a specific client - so does this mean that off-the-shelf provides users with the best of both worlds?
The process of software and systems development is a difficult one involving highly skilled people and consuming a great deal of time and resources. However, off-the-shelf systems can be limited in terms of performance, and businesses often find themselves working around the software instead of the software working round them.
Luckily customers requiring support for their off-the-shelf system have the peace of mind of knowing that the software is tried and tested, and support is readily available. Radiant info school Project Management
An alternative way to access the more expensive off-the-shelf products is through a managed services company. They purchase the products and allow clients to use them as part of a managed services contract, which results in a much more cost effective solution.
Although the customer does not then have ownership and management rights, the software is made affordable, and the problem of it becoming outdated and even obsolete is eliminated.
Unless the company has some amazingly unique scenario (that would not have been picked up by the thousands of off the shelf solutions) many companies can buy a suitable off-the-shelf solution that is the result of hundreds of thousands of man-hours of development and fine tuning.
However, the availability of software off-the-shelf at very low prices bears no comparison with the cost of the processes involved. The low prices are the result of mass marketing - meaning that many companies within the same market sector have access to the same software, so there is no competitive advantage to be gained from it.
If existing processes or those that a company is wishing to develop are unique to the business, products or services, then a bespoke solution is likely to fit better. It will deliver a more appropriate result than a commercial off the shelf solution.
A third option to consider is a compromise between off-the-shelf and bespoke solutions. Specialist IT companies can develop systems using a mixture of commercial off-the-shelf software which can be modified by them to fit in exactly with the customer's requirements.
By matching the needs of the customer to an existing product, the challenge is then to integrate it seamlessly into the company, with little or no disruption to existing working practices. This provides an immediate competitive advantage to the customer who is not then operating the same system as direct competitors.
The Pareto 80:20 principle can be applied to this scenario. Having 80 per cent of the application already available enables the remaining 20 per cent to be configured specific to customer requirements.
This type of environment is especially suited to workflow or process driven requirements, where the engine and administration aspects of the application are already available and the 20 per cent bespoke configuration allows rule sets and process specific to the customer to be easily implemented.
Other benefits that become apparent are the cost savings. Modifications or additions to an existing software package shouldn't run into the tens of thousands of pounds that a full system development would cost. This is a much more manageable project for an in-house IT team that also has ongoing IT issues to deal with.
As products become more sophisticated and the population as a whole, more computer literate, it is possible that future off-the- shelf software will become more versatile than it already is. However, bespoke systems will always lead the field, with off-the- shelf software merely mass copies of successful bespoke designs.
The real challenge that lies ahead is how to combine the two to capitalize on the strengths of each whilst eliminating the weaknesses. Customers are increasingly demanding 'smart' solutions, and more companies need to respond by offering them. Radiant info school Project Management
Commercial, off-the-shelf (COTS) or simply off the shelf (OTS) is a term defining technology which is ready-made and available for sale, lease, or license to the general public. The term often refers to computer software or hardware systems and may also include free softwarewith commercial support. COTS purchases are alternatives to in-house developments
The factors that would favour OTS include:
• fixed price
• as same package sold to many people may be economies of scale - lower price
• can see package in operation
• immediate delivery - do not have to wait for the solution to be developed
• expertise in using the package is more readily available both from the supplier and on the general market
The disadvantages of OTS include:
• customer still needs to do many tasks such as requirements analysis
• a package may not meet organization’s precise requirements - you may need to either
customize the system or build add-ons
• you have the same application as other people: it will not give you a competitive advantage
• you are dependent on outside suppliers for upgrades - as you are tied to the supplier these might be expensive
• risk that supplier ceases trading etc.
WHAT ACTIVITIES INVOLVES IN OTS PACKAGE
1. Formulation of business case - to establish economic case for new OTS
2. Requirements gathering - identifying what the current processes are; what the current ICT
provision is, what the operational requirements are
3. Package evaluation and selection: identifying potential suppliers and products; checking the Radiant info school Project Management
features of each product against organizational requirements
4. Customisation/integration. Package may need to configured for use in the particular
organization. Additional elements of software may need to be developed at the front-end or to
integrate with other applications in the organization.
5. Training
6. Installation - including data take-on or transfer from old system
Agile Project Management Agile project management takes the ideas from Agile software development and applies them to project management. Agile methodologies generally promote a project management process that encourages stakeholder involvement, feedback, objective metrics and effective controls Agile Management or Agile Project Management is an iterative method of determining Requirements for Software and for delivering projects in a highly flexible and interactive manner. It requires empowered individuals from the relevant business, with supplier and customer input. There are also links to Lean techniques and 6 Sigma. Agile techniques are best used in small- scale projects or on elements of a wider programme of work
• Adaptive Software Development (ASD)
• Feature Driven Development (FDD)
• Crystal Clear
• Dynamic Software Development Method (DSDM)
• Rapid Application Development (RAD)
• Requirements planning phase (a workshop utilizing structured discussion of business problems)
• User description phase – automated tools capture information from users
• Construction phase – productivity tools, such as code generators, screen generators, etc. inside a time-box. (“Do until done”) Radiant info school Project Management
• Cutover phase -- installation of the system, user acceptance testing and user training
• Reduced cycle time and improved productivity with fewer people means lower costs
• Time-box approach mitigates cost and schedule risk
• Customer involved throughout the complete cycle minimizes risk of not achieving customer satisfaction and business needs
• Focus moves from documentation to code (WYSIWYG).
• Uses modeling concepts to capture information about business, data, and processes.
• Accelerated development process must give quick responses to the user
• Risk of never achieving closure
• Hard to use with legacy systems
• Requires a system that can be modularized
• Developers and customers must be committed to rapid-fire activities in an abbreviated time frame.
• Reasonably well-known requirements
• User involved throughout the life cycle
• Project can be time-boxed
• Functionality delivered in increments
• High performance not required
• Low technical risks
• System can be modularized
• Scrum
• Extreme Programming (XP)
• Planning game – determine scope of the next release by combining business priorities and technical estimates
• Small releases – put a simple system into production, then release new versions in very short cycle Radiant info school Project Management
• Metaphor – all development is guided by a simple shared story of how the whole system works
• Simple design – system is designed as simply as possible (extra complexity removed as soon as found)
• Testing – programmers continuously write unit tests; customers write tests for features
• Refactoring – programmers continuously restructure the system without changing its behavior to remove duplication and simplify
• Pair-programming -- all production code is written with two programmers at one machine
• Collective ownership – anyone can change any code anywhere in the system at any time.
• Continuous integration – integrate and build the system many times a day – every time a task is completed.
• 40-hour week – work no more than 40 hours a week as a rule
• On-site customer – a user is on the team and available full-time to answer questions
• Coding standards – programmers write all code in accordance with rules emphasizing communication through the code
Commonsense practices taken to extreme levels
• If code reviews are good, review code all the time (pair programming)
• If testing is good, everybody will test all the time
• If simplicity is good, keep the system in the simplest design that supports its current functionality. (simplest thing that works)
• If design is good, everybody will design daily (refactoring)
• If architecture is important, everybody will work at defining and refining the architecture (metaphor)
• If integration testing is important, build and integrate test several times a day (continuous integration)
• If short iterations are good, make iterations really, really short (hours rather than weeks)
• Rational Unify Process (RUP)
Radiant info school Project Management
What is Timeboxing?
TimeBoxing is a tactical approach to project management where out of the key triple constraints in project implementation namely time, cost and scope, the constraints time and cost are normally taken as relatively fixed, whereas the scope (specification or requirements) attribute is relatively variable.
This implies that the project such as the software development is planned in such a manner that the modules in the projects are identified and are split in the separate time boxes (different modules with different time periods). The deadlines and budgets for each time box is allocated. The focus is on the time boxes and the intention is to incrementally finish one module at a time so that the project can be delivered successfully.
The TimeBoxing is particularly suitable for the project contracts in which the deadline is the most critical factor for the client and the complete requirements of the projects are still to be identified or specified.
The TimeBoxing is mainly a popular approach in agile software development process, the rapid application development software deployment process or Dynamic Systems Development Method (DSDM).
Jad
The Joint Application Development (JAD) methodology aims to involve the client in the design and development of an application. This is accomplished through a series of collaborative workshops called JAD sessions. Two employees of IBM, Chuck Morris and Tony Crawford, developed the JAD methodology in the late 1970s and began teaching the approach in to the 1980s.
In contrast to the Waterfall approach, JAD is thought to lead to shorter development times and greater client satisfaction, both of which stem from the constant involvement of the client throughout the development process. On the other hand, with the traditional approach to systems development, the developer investigates the system requirements and develops an application, with client input consisting of a series of interviews. Rapid application development (RAD), a variation on JAD, attempts to create an application more quickly through strategies that include fewer formal methodologies and reusing software components. Advantages and Disadvantages of JAD Compared with traditional methods, JAD is more expensive and can be cumbersome if the group is too large relative to the size of the project. Many companies find, however, that JAD allows key users to participate effectively in the requirements modeling process. When users participate in the systems development process, they are more likely to feel a sense of ownership in the results, and support for the new system. When properly used, JAD can result in a more accurate statement of system requirements, a better understanding of common goals, and a stronger commitment to the success of the new system
Radiant info school Project Management
Comparison with Traditional or "Waterfall" Project Management
Waterfall, as a Project Management methodology, has been criticized for not being able to cope with constant changes in software projects. The iterative nature of Agile makes it an excellent alternative when it comes to managing software projects.
Agile, however, has its disadvantages. Many believe that it doesn't scale well, hence large software projects are still being conducted in Waterfall. Additionally, since the strength and usefulness of Agile are both exhibited in projects with frequent changes, it does not offer any advantage over Waterfall when it comes to classical projects where requirements are nearly always constant and unknowns are rare, such as construction projects.
To explore the differences between traditional PMI style project management and the Agile approach, the book by Sliger and Broderick[5] is useful. It can also assist those in transition to translate traditional issues and skillsets into this rather different paradigm of software development. (Note that the PMI's "Project Management Body of Knowledge" or PMBOK now also includes agile methods).
Here is a summary and comparison of these and other styles of Project Management.
Twelve principles underlie the Agile Manifesto, including:[6]
. Customer satisfaction by rapid delivery of useful software . Welcome changing requirements, even late in development . Working software is delivered frequently (weeks rather than months) . Working software is the principal measure of progress . Sustainable development, able to maintain a constant pace . Close, daily co-operation between business people and developers . Face-to-face conversation is the best form of communication (co-location) . Projects are built around motivated individuals, who should be trusted . Continuous attention to technical excellence and good design . Simplicity . Self-organizing teams . Regular adaptation to changing circumstances
Radiant info school Project Management
In software engineering, software configuration management (SCM) is the task of tracking and controlling changes in the software. Configuration management practices include revision control and the establishment of baselines.
SCM concerns itself with answering the question "Somebody did something, how can one reproduce it?" Often the problem involves not reproducing "it" identically, but with controlled, incremental changes. Answering the question thus becomes a matter of comparing different results and of analysing their differences. Traditional configuration management typically focused on controlled creation of relatively simple products. Now, implementers of SCM face the challenge of dealing with relatively minor increments under their own control, in the context of the complex system being developed.[clarification needed]
Change Control change control is a process of linked procedures to ensure that all changes requested during a roject’s development are fully considered in a systematic manner, and recorded, before a decision is made whether or not to accept the requestor not whereas configuration management is used to assess the feasibility of a requested change and then to coordinate the implementation of all accepted requests.
When developing and maintaining a product, changes are inevitable. People make mistakes, customers need changes, and the environment in which the product operates evolves. In addition, people constantly develop their knowledge of the problem and their ability to solve it. In software development, it's generally said that the solution of a problem will create new problems. In other words, we get wiser all the time.
The purpose of change control is to be fully in control of all change requests for a product and of all implemented changes. For any configuration item, it must be possible to identify changes in it relative to its predecessor. Any change should be traceable to the item where the change was implemented. Figure 1–9 shows how change control affects and is affected by its environment.
Figure 1–9 Change Control in Context
Inputs Change control is initiated by an event. An event may also be called a wish for modification but need not be expressed as a clearly formulated wish. In this context, an event is any observation of something surprising, unexpected, inconvenient, or directly wrong during usage of the configuration item. It may, for instance, be Radiant info school Project Management
A wrong formulation, caught during the review of a document
A coding mistake found during a walk-through of a piece of source code
An enhancement request arising from a new idea from the customer during work on the project
A mistake found in the integration test
A wish to expand or enhance the finished product, arising once the product is in operation
An inquiry to a helpdesk about a problem in connection with usage of a system
A change required in the code because of an upgrade to a new version of the middleware supporting the system, which may not be backward compatible
An event should be documented in an event registration, which is the input to the change control activity. Some changes, such as those due to a review, can be foreseen and planned, while those due to, for instance, a new customer request cannot.