Having established it looks like there's a real need or opportunity the temptation is to run with the solution you dreamed up that morning en route to work. But there might be a better way of meeting the need than the first one that happened to pop into someone's head.
Hold a brainstorm meeting (some prefer the term 'mind shower') with business and IT people. This of course will be one of the activities in the plan for your project definition stage for which line managers have committed people. Describe the 'problem' and then for an hour or so see how many solutions the team can come up with. Write down the solution ideas without critiquing them. Even an illegal idea might later spawn a really good (and legal) idea. It's not unusual to get a list of twenty or thirty solutions. Eliminate the whacky ones to arrive at a short list of solutions which could potentially fly.
For example:
These are radically different solutions that will have different timescales, costs, benefits, risks and strategic fit. We need to assess these solutions sufficiently to be able to choose one. A feasibility study may even be needed to see if some solutions would be technically feasible. Indeed, in some large, leading edge projects where feasibility is uncertain, a feasibility study may be the very first thing that is done. However, even if technical feasibility isn't in doubt, check for 'organisational feasibility': does your company have, or could it acquire, enough technically skilled people and enough appropriately skilled business people to take this project on in addition to everything else the company is already committed to doing.
(For projects that will buy and install a software package the choice may just be between several packages in which case a lot more detailed work may need to be done to match the company's requirement to the functionality of the packages before the choice can be made. If the packages on offer all have roughly the same cost, the broad business case can be built before the package is selected. And in fact package selection may be made at the end of the Requirements Analysis step. In that case, during the Requirements Analysis step the functionality of each competing package is compared to the company's requirement and the best fit wins. Competing packages often all seem to match the business need at the headline level and it's only when one gets down to the detail that the true fit can be judged. An example of a different project 'manufacturing process'. It is so important to be clear what manufacturing process your project will follow before the project starts.)
For the sake of illustration we will say that the solution that comes out top for our project is to write a new bespoke software application.
Bearing in mind we're only about half way through the project definition stage, is it too soon to be choosing
the outline solution? It isn't. We must make the choice now otherwise we would not be able to do the next step.
We can now start to build the cost benefit case. Clearly you can only estimate what the solution might cost when you know what it is.
The Finance department may have a list of typical major project cost areas and standard rates for converting people's hours into money:
The above non-cash expenditures, having been converted at relevant rates, can be added to cash outgoings such as
to give a total monetary cost. You may even co-opt a couple of people from Finance for a few days to help you build a project business case (and maybe things like monthly budget forecasts) that will meet the Finance Director's stringent requirements. Of course, the couple of people you co-opt are amongst the 25 whose managers committed them at the outset.
If this is an IT project, who is going to estimate the IT development cost? Clearly it has to be IT. It can take a lot of time and effort for the IT people to get sufficient information about what is proposed even to give a ballpark estimate. Again, these IT people are among the 25 whose availability you negotiated and secured in writing before project definition began.
Is there such a thing as a project benefit that cannot be quantified in financial terms? No. Every benefit can be quantified. Seeking a million dollars for a project that will 'improve staff morale' will guarantee you a quick exit from the Executive Suite. Seeking a million dollars for a project that will halve staff turnover and thus save two million dollars a year in training and other costs will probably get you a sympathetic hearing. You must at least quantify enough of the benefits to justify the project - any that you choose to leave unquantified may be icing on the cake. Naturally, in small projects the business case will be much less formal but the principle of cost justification should nevertheless be adhered to.
Only business people can assess the benefits this project will yield. It could take many people many days to get a quantified understanding of the likely benefits. Again, these people's time will have been committed at the start of the project definition stage. We begin to see that 25 wasn't such an outlandish number after all.
Let's recap. You had an idea, sold it to a Director who now thinks it was his idea and he asked you to do a full project definition which he will fund. You planned the definition stage (which actually you more or less did before you went to the Director), researched the business need/opportunity and found there really is a business opportunity, considered many ways of meeting that business opportunity and chose one. You then worked out the ballpark costs and benefits and the business case suggests a really good return on investment (ROI) and, given the ROI, you get the nod to carry on (or put another way, if the business case obviously didn't stack up you would stop at this point).
All of those steps are easy compared to the next step, because in the next step we have to decide what we're actually
going to do.
...next
Project Management Book
Copyright M Harding Roberts 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024
This book must not be copied either as is or in modified form to any website or other medium
www.hraconsulting-ltd.co.uk
Home Sitemap Contact Us Project Management Articles Project Management Book