Showing posts with label project. Show all posts
Showing posts with label project. Show all posts

Friday, May 21, 2010

When should I engage my IT resources in a business initiative?

Ever been in this situation? You are meeting with business stakeholders and they present a new idea that needs technical solutions. You made sure you clearly understood the mission, goals and requirements to bring the idea back to your Information Technology (IT) resources. Are you really ready to engage IT ?

No. Your IT resources are precious and you don't want them scoping every idea that comes along. I would propose going back to the beginning of this scenario. It is not enough to understand the mission, goals and requirements of an initiative. You also need to understand the business problem, value and priority.
There are some basic questions I ask of the business before bringing IT resources into the mix.

1) What is the problem the business is trying to solve? So often we jump into solutions without truly understanding the real problem. Maybe the problem could be solved via a process vs. a system. If that is the case, you likely saved you IT partners at least 8 hours of scoping.
2) What is the business value? You are going to need this to do any type of ROI, so get it up front. If the business has not thought this through, help them figure it out.
3) What is the priority of this effort to the business? Do they understand that scoping this initiative may take people off of other projects or slow projects down? If you clearly lay out the time commitment and the trade offs for the business, they will make the priority decision.
4) Once you understand the problem, value and priority to the business you can create the mission and the goals WITH the business.
5) When gathering the basic requirements, be sure to clarify the priority of the requirements. Which are "must haves" which are "important" and which are "nice to have". This will help your IT resources determine cost estimates for different scenarios.
6) Realistically, when do they want this initiative delivered. Everything can't and shouldn't be delivered in 3 months. The timing will affect the cost. You have to understand scope and timing before you can ever estimate resources/cost.
7) Does the business have a budget in mind? I am not talking exact numbers, but I am talking about ranges... under $250k, up to $500k, $1M? If you know the business value and you understand their budget constraints you have a clearer picture. You won't always be able to get to this... the business may say- "I have no idea, can you give me a ballpark of how much you think it will be?". I would advise that you not give any ballparks until you have looped in your IT partners!

Until you understand all of these questions, I would suggest you let your IT resources work on their current priorities. Asking these questions and coming up with a true business case will not only save you time, but it will also save you money. I would also advise that this become a process. Everyone should clearly understand what needs to be done before an initiative is brought to IT. I promise you, this WILL pay off in the end.

Thursday, March 25, 2010

Just get it done or get it done right?

This is an age old question that plagues a lot of companies and folks working on projects, "Do I just get it done, knowing there will be issues or do I take the extra time and do it right?"
9 times out of 10, my answer is "do it right", but you have to step back and look at the big picture to determine that..
My first step is to lay out a concise 1 pager with my team's input. This should be written for the stakeholder and include the following:
  • What is the vision and goal of the project?
  • What is the issue/s?
  • Why did it happen? (be VERY concise here)
  • What affect will the issue/s have on the project? Is there additional cost? How much?
  • What are the pros and cons of delivering on time, but not on scope?
  • What are the options?
  • What is the recommendation and why?

It is critical that you understand the bigger picture, that you ensure your team is on the same page Then you need to communicate to the stakeholders showing them their options and giving your recommendation. There is nothing worse than being a stakeholder and being told what is going to happen vs. understanding the options. Stakeholders will be more on board if they know you have thought this through and your recommendation is something you've discussed with your team.

I can always handle bad news if it is shared openly and worked through thoughtfully. It is when I am surprised and the issue is not analyzed that my radar goes up.

Every project you work on will have delays and issues, it it how you analyze, create solutions and communicate that makes the difference!

Friday, September 11, 2009

From Failure to Success

In the 10 years I have managed projects, I have taken over many troubled programs and projects. Including some that were so far gone that they in jeopardy of being cancelled. In every instance, we, as a team were able to turn those projects around and make them successful.

In this blog I won't go into the "hard project basics" like the project plan, the work breakdown structure or the QA plan. Project methodology is important and critical to a project's success. I am making an assumption that all talented project managers know these tools. My question is how you truly lead a project out of trouble when you have those "hard project basics" in place? You start with what I consider the basics of successful project leadership.

I would caution that you have to work quickly, but carefully... you likely only have this one chance to turn the program or project around. I approach troubled projects the way I approach all projects:

1) Stakeholders: Meet with the stakeholders. Start at the top. Are they all in agreement as to what the vision and success metrics are? If not, this is likely the root of your problem. Taking the time to clarify the vision and success metrics will save you a lot of time and money in the future. The stakeholders will all need to meet together and look each other in the eye and agree. This lays your foundation for a strong program and/or project.
.
2) Team: Meet with the team, together and individually. Does your team clearly understand the vision and success metrics? If not, find out why they were unclear. Find out why they think the project is failing and what they think the team should do to turn it around. Let them be part of the solution. Lead them to the solution, don't just solve it for them! If people feel like they are part of a team that is turning things around, they will act like a winning team. Each member is part of the team and they have a responsibility to each other. This can be tough to instill, but it is important.

3) Clear communication and escalation paths
If the vision and success metrics are clear and the team understands them, how could a project be in trouble? Without clear communication and escalation paths a project can fall apart. I've been on projects where folks are "punished" for giving the bad news. That is exactly what you want your team to come tell you- what is going wrong? It is your job to coach them through the tough spots and remove road blocks so they can get their job done. If they don't understand how to escalate problems- you've just created a problem- a big one!
Communication is such an overused buzz word and an under-utilized reality. Think of how many projects you have been a part of. Has the communication between teams been good or strained? Does the right hand know what the left hand is doing? Clear, concise, actionable communication is imperative for the success of a project.

4) Celebrate Successes: This is important with all projects, but it is crucial with troubled projects. The team likely feels beaten down and unmotivated. Tell the team that them successes will be celebrated and then do it- big or small, successes should be acknowledged and celebrated Let the team feel the success- they will work harder and smarter. They need to know that what they are doing matters!

The question often asked at this point goes back to those "hard project basics"... what about the inter-dependencies, what about the contingency plans, what about the Gant charts? When managing a project it is your job to ensure all of these tools are in place- these tools are the foundation of managing a project. When truly leading and turning a project around, you need to call on the "softer project skills"... in the end, they are "harder" to do and make the difference between mediocrity and excellence.

Wednesday, August 26, 2009

3 steps for any successful strategic implementation!

Question: What are the steps for successful strategic implementation?
Answer? It depends on the program or project, but these are the first 3 steps that will make you successful in any implementation.

1) Is there a clear vision and goals? Do the stakeholders agree and can you clearly articulate this to the organization? If the answer is no, DON'T move forward with the project until this is clearly defined. It is imperative that the team understand the bigger vision and goals.
2) What are the success metrics? If the stakeholders can't articulate or agree on the success metrics, DON'T move forward with the project until there are success metrics. What is the strategy going to measured against? How will you know if it is successful? The team implementing the strategy needs to understand what the measures are to ensure they execute the project strategically.
3) Have you communicated to the team?: Clear vision and goals along with agreed upon success metrics give your team a compass to travel by. Ensuring that the vision, goals and success metrics stay front and center is your job as a leader. Be sure the vision and success metrics are on every document that is shared and that you start every meeting with this same information. Focusing on these will give your team a critical tool they need to determine the "right path". If something they are working on will not meet the vision, goals or success metrics, they know to question their path.

I know this seems simplistic, but it works!