Problems hindering a successful project:
To make any project successful, requirements and project objectives should be prioritised properly. Though few methods were followed for the prioritization, but still the results were observed to be flawed.
Problem 1: Prioritizing the Project Requirements
An important factor for any project to
be successful is to ensure that the requirements are prioritized.
Sometimes it is the customers’ fault who wants the entire system to be
delivered now or it is the project manager’s fault because they do not
discuss the project with the customer.
However prioritising
is not an easy process, and on using number system people found it
troublesome to prioritize requirements by 1,2,3 etc. However who wants a
requirement to be a “2″ or even a “3″? As a result all requirements
become a “1″, which is useless. So effective prioritisation is important
but how can it be done if number systems are not effective?
Problem 2: Prioritizing the Project Objectives
When a set of requirements has been
prioritized then key project objectives of the project such as scope,
quality, timescale and resources should be prioritized.
If nearly all requirements are
prioritised as “Must”, then there is not much flexibility in the scope
of a project. However many studies have shown that it is better if a
project is delivered on time, even if it has few features, than if a
project is delivered late, but with a full set of features.
If quality is sacrificed then faults
will occur in the software. One way around this is to train the users in
the use of a new system, so that they only use it in proper fashion,
and know how to get around any bugs that are discovered.
Finally all systems must be produced to a
budget, and a business does not have unlimited resources to put into a
project. Moreover the business case normally assumes a rate of return,
which will be considerably reduced if the resources are increased
significantly on a project. Therefore resources have a strong case for
being the most important factor.
Regardless you cannot “have it all and
have it now”, and a balanced and planned prioritisation of the factors
must take place if a project is to have a chance of delivering business
value. If it is not then the fifth factor of risk goes sky high, and
ceases to be risk and become inevitable.
MoSCoW Principle
To overcome the above problems we have a useful method MoSCoW which was first developed by Dai Clegg of Oracle UK Consulting.
This stands for
M – “MUST” be
implemented. Requirements falling under this category must be
implemented and should not be left off for any reason. If they are not
delivered then the project is a failure.
S – “SHOULD” be
implemented. This represents requirement should be implemented in the
project if it is possible. If it is found to be difficult to implement
or not possible, then an alternate solution is also acceptable.
C – “COULD” be
implemented. These requirements are considered as nice to have in other
ways not a mandatory one. Requirements mapped under this category are
desirable ones if time and resources permit.
W – “WON’T” be implemented. This requirement won’t be implemented at this time and likely to be implemented in future.
The two lower case “o” were added to pronounce the word easier.
Conclusion
- The requirements.
- The main project objectives: scope, quality, timescale and resources.
To Know More About: MOSCOW

0 comments:
Post a Comment