How to create an astounding innovative project plan when the information is too broad and there is short time to do it

Question

Maybe you remember my last question, where I asked how to leverage my internal knowledge to better handle an internal selection process for project manager. Well, in part because of that advice, I passed the first two stages of the evaluation (against a bunch of guys in the company!) and now I'm here for the last level of the selection.

This time, each of us finalists, were put in charge of real projects for software development with real deliverables and deadlines. The four main deliverables being a project charter for Friday, a kick off meeting for next Tuesday, an impact analysis on ongoing projects and a planning poker exercise for the end of the next week. The project is for a big company in the Oil and Energy industry, and is the third part of three phases for a software development project. Each one of the others phases carried out a backlog of things that were missing when we delivered them, and now is the moment to consider those again. The project has a fixed deadline of March in 2013, and there are some technical and advanced requirements I don't really understand too much (one of my evaluators advised me to not dive too deep there because is not so relevant now).

The problem now was that my priority this week was to complete my usual assignations in my current role because we have to deliver a stable release for the customer tomorrow, and everything was aggravated by the fact that I had to replace another coworker's duties as he went on vacation these days, so as today (Wednesday) I have had too little time to ask questions and to understand better what is the goal of the project, and the bosses and customers are in Germany so the time difference and their other priorities unfortunately clash making everything a little bit harder.

I only have tomorrow for solving this and doing the best of my effort to shine, so I'm here again to ask you what can be the details making a substantial difference in a project plan with too little information. The point, I believe, is to do the basic stuff but going further and propose innovative elements and impress everyone so my evaluators can be convinced I'm a better fit for the position. I personally think this selection has been particularly exhausting, hard and long but I'm really interested in getting the job so any other experienced viewpoint surely will be useful.

I only thought of, in addition to the basic sections (requirements, success criteria, team, and communication plan), expand on the methodology to explain a practical way where we could improve the metrics for the control of the progress for the project, and where we could estimate velocity and projections of completion date in a systematic manner taking advantage of tools like Microsoft Application Lifecycle (supported on TFS 2010 and better integration with MS Project and stuff like that).

What are other elements you think could make a massive difference in a project charter and, more generally, in the formulation of a project like this? Objectively, where do I have to put my main effort here?

What do you recommend it can be done to better handle this, I mean, to improve the impression for my evaluators and so on?

Answer 1

Two suggestions -

"and propose innovative elements and impress everyone so my evaluators can be convinced I'm a better fit for the position."

I would stay away from trying to be "too clever". You're trying to convince them that you're the best person to 'manage' the project, not that you're the most technically gifted. Focus on the management aspect of bringing 'their' project to fruition, when they want it.

And 2, go in with what you have. As a PM, you're going to be faced with a situation exactly like this as some point - not enough info, not enough time, etc. So go in with that mindset - if faced with this situation in reality, what would I need to do.

And find a way to work that into your presentation. Start the interview by explaining that you put this together while still completing your other responsibilities, and so 'yes, some of the requirements were not clear or missing, but even with that, here's how I'd get that info, and how I'd manage your project to success'.

It shows that you can think on our feet, and that you don't need to have every detail spelled out to be successful. You know how to adjust and adapt, and most of all, find the info you'll need.

Answer 2

and there are some technical and advanced requirements I don't really understand too much (one of my evaluators advised me to not dive too deep there because is not so relevant now).

For starters, learning more about subject domain (Oil, Gas & Energy) is indicated (evaluator may have a hidden agenda). Benefits:

• Understanding customers
• Understanding development hurdles
• Gaining respect of team members

Drawbacks:

• Spending some time with the books.

From your post I can also see you're a bit elated. Please consider drawing a breath and calming down. Astounding innovation may not be what your project needs, if you start pushing methodology changes against the grain of the team instead of getting things done, you may be facing problems soon.

Answer 3

I don't think you need innovation so much as you need to focus on basic principles. The key buckets of information that you should look to include in your charter:

• End user interests. What does the client need to have and why? What does the client want to have and why? What are their priorities in terms of time/cost/scope/quality? What are their key risks and assumptions? How do they want to be involved?
• Supplier interests. What can the people preparing the product deliver? What resourcing/training/experience issues do they face? What are their key risks and assumptions?
• Business interests. Not the interests of the client, but the interests of your organization. What drives the need for you to complete this project? At what point in cost or time or effort does the project lose value? Remember that a project should only move forward if there is a justifiable business case, and your project is a failure if you deliver on time/budget/scope but such a business case does not exist.

Get the end user requirements and get them "in a room" with the leaders who will generate those requirements so that issues can be raised and questions asked. Make sure assumptions between the two groups are shared. Put your effort into making sure clients and suppliers are on the same page before you start doing work and base your plans on that. Then make sure your plans accomodate your company's business interests.