Change Reqest Management

Given that a project is a dynamic process, it is unrealistic to assume that requests for change will not occur. These changes will originate from changes in the user requirements and/or difficulties in realising the user specification in practice. Project Management via the Project Management Office need to manage the process and at Picaso Consulting we support in ensuring that this process is run effectively and efficiently.

One of the most effective methods of dealing with the need to amend projects is to have a project change procedure. Although this procedure will not remoe all risks, it will enable some changes to be made with minimal disruption and slippage. These request for change will occur in all implementations and it is vital that the process is well managed.

The Change Request Management plan is a definition of the formal process for making changes to the project’s original scope. It generally involves redefining existing objective and deliverables or specifying new project objectives and deliverables. The procedure for changes is as follows:

Change requests should initially be awarded a change priority classification code based on a set of standards. These can be either simply alphanumerical, or descriptive such as Critical, High Importance, and Medium Importance etcetera.

After the change request evaluation, the project manager should schedule a change decision meeting. Participants in this meeting should include the project sponsors, the change review committee, the project manger, the originator of the request, as well as any other interested and affected stakeholders.

The project manager will present the proposed change and the results of the evaluation, including a copy of the proposed project plan illustrating the impact of the change. The requestor may choose to speak on behalf of the change and the evaluators may also choose to defend their evaluation, if necessary. The project manager should only become significantly involve if the evaluation indicates that the proposed change would have a significant effect on the overall project in terms of finance, scheduling, or the eventual effect on the project’s service or product.

In all but very minor cases, the later that a project change is made, the more difficult it will be to implement without significant repercussions. The ramifications of the change will also vary proportionally with the size of the change. It may be that minor adjustments here and there may have a negligible effect, but a significant change in scope may set a long project back several weeks, months, or even years.

In short, a change request management procedure for any given project should include, but not necessarily be limited to the following:

- Identifying the need for change.
- Change recommendation.
- Analysis of the feasibility of change.
- Steering committee approval.
- Project sponsor approval.
- Amendment an agreement on the revised project plan.
- Implementing the change.
- Continue constant review.

The final task is to communicate the revised change request plan to all project team members and stakeholders, explaining the rationale where resistance is encountered. It is also important at this point to ensure that the minutes of meetings, decisions reached and agreements made are documented and retained.

In conclusion, change should be expected in any given project, but, as discussed in this article, is very much a manageable issue of the simple steps discussed above are followed.

Picaso Consulting consults in Strategy and Technology. We optimise your Business through Business Consulting and IT.

System Implementations

Sound planning of the implementation is crucial to its success as poor planning and inadequate resourcing are often primary causes of System Implementation failures.

The scope of most implementation can be huge. Not only does it include installation of the new software and the hardware it is to run on, but also precipitates panoply of potentially difficult and unavoidable human factors. Appreciating the conflicts that may arise will enable the organisation’s management to predict likely trouble spots and mitigate accordingly and in good time. Picaso Consulting can help you predict the likely troublespots and help you in unlocking the value within your organisation.

The key skill is for the company’s management to understand that the new system by itself is not some sort of silver bullet. The entire implementation process involves the complete business process and/or pedagogic practice, customer service, interaction with suppliers and a bond with all other interested stakeholders. Many less tangible activities are crucial and those involved must:

Have a sound understanding of the organisation, particularly in terms of its culture and values. The rationale behind any new system implementation should have thoroughly considered how the system is likely to help provide a better service to all concerned with it;

Undertake a very comprehensive review of all business processes and, where necessary, pedagogic practice, and begin to develop and introduce new policies and procedures before tuning the system to meet the agreed requirements;

Have a complete appreciation of the complexity and flexibility of the system;

Have an understanding of the inherent dangers of customisation of any software and how these can be mitigated against;

Conduct a thorough set systems testing procedures, whilst accepting the potential need for software 'bug fixes' and upgrades;

Budget for the real costs of internal staff time and their training and development;

Train all users to use the system and to fault-find and correct autonomously;

Acknowledge the critical nature of system documentation;

Careful planning and efficient management of the implementation are vital to success and to negate the threats of spiralling costs, extended timescales, losing key personnel and general dissatisfaction with the outcome.

Finally, it is crucial that the “go live” day causes as little disruption to the day-to-day business as is reasonably practicable. Issues that only arise at this juncture become magnified and will undeniably adversely affect the organisation's reputation, sometimes irrevocably, with all stakeholders. It is important to remember that poor project management and lack of communication at this crucial stage can ruin an otherwise faultless implementation.

The Importance of Project Management

Picaso Consulting 's Alfonzo Venturi comments that one of the key purposes of Project Management is to predict as many negative potential outcomes in a business venture as can be reasonably foreseen; and to implant effective mitigation strategies into the system such that the project is completed as successfully as practicable in the face of the identified risks.

The omnipresent nature of uncertainty in every business model means that events and tasks leading to a project’s completion can never simply be unfolded with unequivocal predictive accuracy. Moreover, for some innovative, groundbreaking and complex projects, even the possibility of successful conclusion is by no means a certainty.

The discipline of Project Management has developed in order to plan, co-ordinate and control the complex and diverse activities of modern industrial and commercial projects and thus remove as much of the controllable risk from the business system. In industries such as pharmaceuticals, software, aerospace, and defence projects drive a much larger proportion of the business and, as such, the discipline’s importance is absolutely paramount.

Project Management’s importance has it roots grounded in the way in which it secures the venture’s desired outcomes, usually in the form of SMART objectives. These can be set under generic headings such as:

Performance and Quality.
Project Management will ensure that the end result equates to purpose for which it was intended. Previously, quality was seen solely as the responsibility of a quality control department, but, with the advent of Project Management concept of Total Quality Management has come increasingly into vogue, which has shifted the responsibility of quality upwards to the Strategic Apex, as well as the Operating Core.

Budget.
Across all industries, margins are steadily decreasing and the need to bring in projects on, or under, budget is becoming a sine qua non in every business undertaking. Financial sources are never an inexhaustible resource and projects often end up abandoned when the allocated funds are used before the project is completed. Poor project management in this area precipitates significant waste in money and effort, as well as bringing some severe criticism of the project’s SRO. In some extreme cases, the project contractor could find their public standing reputation ruined beyond repair.

Time to Completion.
With ever shortening business cycles and the rapid pace at which business takes place, successful project management is important to ensure that all delays are identified early and mitigating action put in place to ensure that the project is brought back on track. All significant stages of the project must often be complete the specified dates as failure to do so can delay milestone payments or incur significant financial penalties. Additionally, late completion of projects can also damage the contractor’s overall reputation and may make repeat business harder to come by in the future.

Conclusion
Project management has become on of the most important skills that any company or contractor should have as an integral part of their overall service. It can be argued that effective project management is equally as important as the technical ability or level of service provision as allowing the failures highlighted in this article to materialise can have significant negative consequences for the SRO and contractor, and, indeed, the economy as a whole.

Picaso Consulting can support you in achieving your objectives.

System Software Testing

For all bespoke systems, whether written in house, or externally, or, indeed, any off the shelf packages that have been adapted, testing is an integral part of the system’s development process and we follow this at Picaso Consulting

Testing normally roughly follows the structure of the well known V-Model, although some testing systems do recognise a simpler, four stage testing procedure as outlined in this article. Testing, therefore, can be broken down into four elementary stages:

Testing the logic of the system
The technique of dry running can be used to make sure that the logic that has been set down by the analyst is correct. The programmer or analyst will trace, often by hand, the progress of a number of sets of data through the system’s schematic diagram or flow charts. If all data follows produce the results that are expected, the individual programmes can then be written.

Programme Testing
Each program is then thoroughly tested with test data, which is carefully selected to make sure that all of the sections of the programme are working properly. This part of the testing process should be documented very carefully with the data being tested, expected results, actual results and any discrepancies being recorded and sent for further investigation.

The programme testing documentation created at this stage is of vital importance for overall system knowledge and is critical for subsequent system maintenance.

System Testing
Once it has been established that the individual programmes are working correctly, the system should be tested as a whole. This is an equally important task, and the results should be documented in the same way as those for testing programmes. It is not only the software that is being tested during the system testing process, it is also important to test operating procedures and the human-computer interface, for example.

System testing can be carried out prior to installation or immediately after implementation. The maxim holds that the more pre-installation testing that is carried out, the lower the risk of failure following installation. However, this offline testing cannot always find all of the problems within a system as some will only appear during the live phase of testing.

Acceptance Testing
The final phase of testing needs to be carried out by the eventual users of the system and this will be the first opportunity to do this as the previous testing procedures should have been completed by the system programmers and analysts. It is probably of greater importance to ensure that the eventual users of a system will accept it as whether or not it actually meets the initial specification. Users will normally operate the system with dummy data and their use of the system will be monitored very closely. On completion of this process, the users will report their objective and subjective findings in order that final refinements can be made, where necessary.

The involvement of the end users does not however, have to wait until this point as their early involvement will undeniably assist in identifying potential difficulties earlier in the design process.

Conclusion

The four stages of software testing here also correspond to the well known software development lifecycle where each phase of software writing is matched by a corresponding phase of testing, which, in turn links to the V-Model as used throughout industry today.