Project Scheduling – Scheduling, Earned Value Analysis - Risk Management

Project Scheduling – Scheduling, Earned Value Analysis:

Software development is an extremely dynamic and fluid business, and it is difficult to plan everything at the beginning of a project. Therefore, efficient management of software projects must be based on some explicit, strategic goals and organization's interests. There are a number of useful lines to follow in that sense. Some of them are balancing the need for structure and process control in software development with the need for flexibility, informality, and more effective communication processes;

establishing software measurement programs and and enfocing accountability for completion of software development milestones;

making management objectives and product vision clear to the development team members (this is very importnt in practice, because far too often developers are in total ignorance of the broader strategy of a company, and the tactical decisions made by management to advance this strategy seem to them arbitrary and even hostile);

identifying the most critical issues of the project and stressing the need to allocate most development resources, time, and efforts to such issues;

organizing more visible and formal management processes for reviewing and approving potential product enhancements;

emphasizing management approaches that facilitate flexibility and creativity within clearly defined boundaries.

keeping-up with technological developments by enforcing life-long learning, training, courses, and seminars;

developing more globally focused, culturally sensitive management capabilities;

involving end-users in the development process in order to constantly provide advice on using the product in the real world, thus eliminating the customer-developer gap;

promoting orientation towards strategic business partnerships.

There is also a large number of managerial techniques that help monitor software product development on the day -to-day basis and make tactical decisions relevant to the development process. maintaining progress charts that show the percentage of completion for each module, at any given moment of product development;

keeping track of all relevant facts about the product (e.g., previous versions, delivery dates, current version), the development process (the problems encountered, resulting delays, and the reasons why they have occurred), and discarded design alternatives in the external group memory (it is usually a special-purpose project-management software, or a site on the organization's server or Intranet, and sometimes even a site on the Internet); the external group memory can also serve as a board for discussion on all the relevant ideas that arise in the course of the project;

estimating time and effort needed for each designer to complete a short-term task, e.g. an iteration in an iterative development process; for that purpose, each designer may be required to initially fill-up and constantly update a planning sheet that contains both the designer's original estimates and actual measures (in days) of how long does it take to complete each activity for the task (activities may include analysis, design, coding, testing, and so on);

emphasizing progress review mechanisms across the development effort;

applying mechanisms of recognizing, rewarding, and leveraging extraordinary efforts and/or hyperproductivity, as an avenue to promote and retain key technological leaders;

adapting the software development process to the characteristics of the product being developed; increasing parallelism in product development by reducing linear, sequential activities, encouraging relevant communication and social interactions among the team members, and changing the work modes

when necessary;

insisting on creating multiple design views, such as structural, functional, object-oriented, event-based, and data-flow; although sometimes redundant, multiple design views help cover design from multiple perspectives and make it more complete and more efficient; enforcing the feedback mechanism in the development process, in order to detect inconsistencies in design as early as possible and reduce the costs of fixing them.

Risk Assessment

In order to prevent project runaways, meet deadlines, stay within the project's budget, and simultaneously maintain the product's high quality standards, it is essential to timely identify and periodically evaluate certain critical factors. Such factors include

estimating the project's size in the early phases - the project's size affects how the deadlines will be set up, and is positively correlated with monetary expense and risk;

setting up the deadlines realistically - as a result, the necessary time to establish the rhythm of the project, prevent delays, and enter a steady state in which the effort is equally distributed from the beginning of the project, without putting an extra workload to the team members at the end of the project phases;

collecting and studying reports on other similar projects - this provides the possibility of learning from the other projects' and other teams' experiences; in that sense, a process data base is essential for an organization that wants to go higher than Level 2 on the CMM level ladder; engineering management depends on measurements, and their proper use, and this data base is to be regarded as an organizational asset, and it is to be properly managed;

top management commitment - if top management does not play a strong, active role in the project from initiation through implementation, then all other risks and issues may be impossible to address in a timely manner;

failure to gain user commitment - when the users are actively involved in the requirements determination process, it creates a sense of ownership, thereby minimizing the risk that the end-user expectations will not be met and that the system will be rejected;

timeliness of additional user requirements - it is essential to have the users involved in the development process from the beginning to the end; however, it is highly preferable to have the requirements frozen

at a certain point in development;

familiarity with technology - the higher the organization’s experience with application languages, technology databases, hardware, and operating systems, the lower the risk in the project; insufficient/inappropriate staffing - the risk of failing to provide adequate staffing throughout the project can be mitigated by using disciplined development processes and methodologies to break the project down into manageable chunks, and developing contingency plans; the degree of structure in the project's outputs - it is negatively correlated with the risk in the project;

In the context of the Unified Process of software development, it is adopted

that one can never fully eliminate risks; at best, one can manage them. For that reason, the Unified Process stresses the need to drive software development as an architecture-centric activity. Architecture-centric approach forces the risk factors to emerge early in the development process and make the process simultaneously risk-driven - when the risk factors are identified early, managers can take steps to mitigate them. Experienced software project managers recommend to maintain a running list of project's top ten risk factors and use that list to drive each release.