Please login or join to subscribe to this thread
For the intake process, here are some steps
1. Identify the scope and which functional and technical area it falls in.
2. Bring the stakeholders into one meeting(typically- tech leads, managers, SMEs)
3. Yes, based on T-shirt sizes, estimate the budget.
4. Fill the necessary documentation based on the size of the project(different approvals from sponsors, finance etc)
one example: less than 500K, internal scope budget, greater than 500K, Director and Sponsors formal approval etc.
Hope this helps.
Pervez, I see you posted this question in 2017. Could you provide an update and let us know about your experience developing a project intake process?
Just to this in the framework of organizations where you can find information, take a look to IIBA´s BABOK and/or PMI´s Practice Guide for Business Analysis.
Does anyone have a strategic Project Intake document they are willing to share? Looking specifically for a scorecard or criteria with which to assess the business need.
Other than using a scoring model, you may want to investigate throughput accounting as another way of deciding which initiatives to proceed with.
I'm putting something simple together, using Microsoft tools - Forms to create a form for submitting the request, SharePoint for the list to review... I've introduced a scoring model, but we're not ready for it, yet.
More important than tools is the process and the amount of information you want to start with. Are you only going to accept fully developed ideas, or do you have the resources to accept some basic information and then work with the submitter to build out the details?
If going the former route, you might have to make your process the ONLY way to get requests approved, or people will take their incomplete ideas and go around you. And they will likely try to go around you, even if your process is the only way.
If the latter, you will likely get a lot of incomplete ideas that go nowhere, and you'll need people to spend time on requests that may end up cancelled. But is this a bad thing?
The above thoughts are an oversimplification. There are more pros and cons to both approaches, and other routes you could take. Figure out most of the process, first, and then spend time on tools. You'll find simple, OOTB tools, tools you can cobble together (which can be great or a maintenance nightmare), and enterprise solutions that cost a lot and require a lot of configuration to use effectively, partly because they are tied to other PM/PPM tools.
This is a subject where I would suggest looking at whatever anyone else has as a suggestion, but business strategy not only differs from company to company, but also over time. I'm the one often tasked with building such a document/checklist, and every time the new year's or new bosses' program strategy priorities comes out, I have to re-align things to the new direction.
The good news is if you want a score card, simple is better. The bad news is that boiling down lots of information into a simple format is anything but simple.
At the top level, you will have Mandatory and Discretionary. Mandatory could be things like business commitments, safety improvements, your CEO's wish list, etc. Discretionary is where you need to pick out your strategic objectives. That could be ROI, projects that are growth opportunities, low risk revenue generation, or whatever is important to your business plan going forward.
How you compare those different strategic objectives is where it gets tricky. You can create a weighting system. You can use fuzzy logic. What I find most valuable however is having the in-depth discussion about the priorities since frequently the prioritizing system is totally subjective.
Not only does that help the business by giving people a standard to follow, it also forces the conversation to make it clear in the minds of everyone else (including above you) what's important today. The career benefit bonus is that as you guide people through that discussion a) You get to learn a lot about your strategic priorities b) You get to frame the output in your own words & c) You are very visible in your role framing the decision making process going forward.
I can write documents and checklists all day. Where my own job security really comes in is having enough the leadership sills to facilitate the conversations among my bosses on what is really important, understanding of the strategy well enough to make value based decisions so I'm a participant in those conversations and not just a scribe, and just enough technical skill to turn the output of those conversations into a document or checklist.
Please login or join to reply