I've been tasked with taking over a project that has run into some troubles and needs saving.  Project is ready to start some testing, but still have various outstanding issues.  I will be meeting with the business owners tomorrow to discuss my new role and where we go from here. 

Does anyone have some thoughts as to where to begin this crusade??  Thanks.....any help would be appreciated.

I would start with an audit of the Requirements Traceability Matrix.  If there isn't one then I would get one organisaed. The next thing I would do is check ff with the stakeholders which requirements are most important and which can be dropped.  Lastly I'd apply my own judgement to what can go and what must stay.

My experience makes me guess the solution has been over engineered, probably, ut not neccessarily, based on poor requirements.

Risk areas include;

• System integration; are you asking for more than you need in context of the business process
• Non functional specs; availability and response times drive hardware costs up quite high when you are looking for 99.7%^ uptime.
• Non strategic requirements; which requirements support the project objective and which ones are there for stakeholder comfort and convenience.

When cutting back requirements and solution design you often have to "sell the benefits" back to stakeholders. 

It's not an easy thing having to come in to a project which is already heading in the wrong direction.  It's very important that you make a reality check upfront - that is, baseline the project where it's at right now and ensure everybody understands the state and trouble the project is in.  A few months from now most people will forget that you are the new business analyst and that you did not create this mess - they will expect you to still deliver as if you've started with a clean slate (things just work that way).

So make sure to:

• convey to the business and management that "miracles" just don't happen: if the project is late with the deadline approaching it would not be reasonable for them to expect for you to make up the loss time,
• understand and document where all the problems and risk are with the current requirements, specifications, etc. - and estimate what would it take for these problems to get fixed; as a new guy you'll be eager to make a good impression, so beware of underestimating,
• identify the root causes of why the project is in bad shape and fix them: if project failed from lack of planning then create a planning process and plan, if the project failed because of missed requirements then institute a requirements gathering and management process, etc.
• again, let the management know that you're not a hero and that it will require significant resources to fix what's broken before the normal process of adding new features resumes.

- Adrian