Copyright Beaver 2000/2005
>> Home >> Life Cycle Overview
||Today business solutions are needed with ever shortening times scales and must deliver true business benefit. However IT and engineering projects implementing these business solutions have a history of failing to deliver with problems such as cost and time over runs, lack of essential functionality, poor performance, or a deliverable that works fine except thats not what the business needed. At Beaver we use a best practice approach based on systems engineering concepts, now embodied within methods such as RUP, RtP, MSF, and DSDM, to specify and deliver business solutions, whether implemented manually, using computers, communication systems, machinery or a mixture of each. And we always recognise the people in the system. In other cases businesses fail to identify the need for a new solution to improve performance or deliver new services or functionality or take advantage of new technologies, products, services or ways of doing business.|
Of course not all of our approach may apply to your project. You may already have done some of the work, if so that's great, we can review it, incorporate it, then build on it. Perhaps for some assignments there is simply not be enough time or it would not be cost effective when addressing the problem at hand. What's important is we know what should be done in an ideal world, and if it is not for what ever reason, we can assess the level of uncertainty the gaps bring and test whether that's important. The basic principles though will still be applicable.
Beaver use a business focused and requirements driven approach incorporating risk management. We seek to understand the business and market, identifying the services needed in terms of functionality, performance, time scales, constraints and business rules, then to support the development and implementing activities with our risk based project management services. This work often involves analysing the present situation and systems and defining the future vision or objective, whether its to just improve existing performance or introduce new services or functionality. We have applied aspects of each work stream on live projects as well as under taking pure process definition and implement assignments for our clients.
Our approach strongly binds the business vision, organisation structure, and business processes to the IT infrastructure and application solutions. Such traceability means the impact of changes between the two can be easily reflected in the other. Our approach allows fast prototyping and testing of scenario based models, allowing you to conduct what-if analyses of alternatives and determine the relative merits of each option. This approach gives confidence that the specification and emerging design actually work and can deliver the business needs. At all stages Beaver works to ensure that the business benefit is being realised, during specification, build, and then on implementation. The main work streams are described on the associated links in the left hand box.
|Our process is not sequential, it is not the classic "V",
rather each work stream under takes a set of activities in each iteration
of a given phase, and they all interact with each other. Requirements
creep has always been a problem on projects however to be realistic we do
not treat requirements as being frozen early on, but recognise they will
be refined as time goes on, and changes may be needed due to market,
business, organisational and technology changes. Such changes need to be
considered in terms of the impact on the programme and the business
benefits and need to be formally agreed. Therefore we use an iterative,
risk based project management approach which integrates each of the work
streams together, with strong configuration management and change control
As we have said we do not advocate a waterfall or sequential approach but rather we recognise each of these activities needs to occur to in parallel, interacting with each other through the life cycle. What is important is that the project is broken up into a number of smaller stages, in which the above activities are iterated, with each main iteration providing useable products. So even from an early stage we produce an early version of the main deliverables as well as the interim deliverables. At the end of each iteration progress can be seen, feed back obtained, uncertainty and risk clarified, measured, and controlled in the next cycle. We believe this is a better approach than delivering the key products right at the end only to find its not actually what was needed. That's why we encourage active involvement of staff during the process.
A key, explicit activity is ensuring the solution still meets the business benefits on which the project has been approved, particularly as changes are fed in, assessed and approved, and the market changes, and as the solution is deployed, tracking monitors that the benefit is actually being realised and if not, corrective action is taken and the VISION and benefits elements of the business case and Project Initiation Document updated. This requires a team effort.
|As an example if our role is to help specify and plan a new software and network system, for example, to support product life engineering during manufacturing or field service CRM, we'll iterate the ITT or user specification a number of times. Driving it from the analysis of the business context, the business model, getting feedback from prototypes or reviewing with yourselves candidate solutions or products. This may elicit further requirements or act to verify the business needs. Even as the contract is then let we still iterate, working with the developer or integrator, ensuring the business model and solution still fit. This requires strong configuration management and change control protocols and project management. It may be different from the way you have worked in the past, perhaps where fixing of the requirements was at contract and then exclusively managed against them. Projects using a more iterative approaches tend to do better, as long as the right processes are in place.|
A key feature of this approach is the constant delivery of products. Whether the product is real system, a machine or business process, even paper based, then it means the changes start to be realised earlier. Reducing time. Responding to the market quicker. A perfect product or process which is 6 months late is going to be a failure - one that is deliverable with 60% functionality early is moving the game forward and providing real feed back to maximise the development opportunity. Talk to us about all or part of our method. Whether its specification development, overseeing systems or process implementation, or managing a particular phase, such as deployment, training or initial problem management, we'll be able to help. If we honestly can't help we'll tell you and try to advise who can.