Showing posts with label methodology. Show all posts
Showing posts with label methodology. Show all posts

Monday, January 28, 2013

The Leader vs The Visionary - 6 Steps on How to Connect the Dots between the Vision and the Product

A lot of people associate leadership with being a visionary as if one quality naturally begets the other.

Unfortunately, this is not so and there are people who are great at visioning an idea but truly cannot lead it to execution. There are also people great at executing but cannot envision a strategy.Vision is important but vision without execution is futile. Execution is important but executing without a vision is folly.

The people we remember the most as having changed history are those that can envision a strategy AND can also see it to fruition.

How do you connect the dots between a vision and its execution? Here are the steps I have observed of the people who I believe were able to not only envision ideas but also saw them through fulfillment.

1. They OBSERVE their current environment and look at opportunities or gaps. It can be a simple product that takes half the time of doing a task or it can be a grand plan of remodeling a city to make it more sustainable.

2. They create possible solutions and define the BENEFITS vs COST for each one(quantitatively and qualitatively)

3. They PRIORITIZE the possible solutions and define risks vs opportunities for each one and decide which solution will make the most sense to do.

4. They further scrutinize their ideas and define what RESOURCES they need to make their visions into reality and start the process of connecting the dots between the idea and the final product.

5. They MARKET their ideas to the relevant stakeholders and get buy in and support.

6. They see their ideas through with such persistence that they don't rest until their ideas either become reality or they realize that the actual cost is costing prohibitively more than the foreseen benefits.

At the end of the day - a visionary who just envisions but cannot fathom how to execute is just a dreamer and a person who just executes without the guidance of a strategy is a lost soul.


Friday, January 25, 2013

How to Estimate Project Cost High Level

Sooner or later, we will alll need to estimate costs and though there is an entire science on this subject and it can fill many books - sometimes you just need a "high level" number or a "ballpark figure" just to assess whether a project will be cost prohibitive or not to do.

I just want to share with you what my "rule of thumb" process when estimating technology project costs and I hope it helps you now and in the future. I found that the numbers I get from this process are within 10-18% of where the science will take me - enough to drive a decision on whether to proceed with the project or not.

My Definitions:
  • Base Estimate - Ideal Estimate assuming all things go right
  • Base Budget - the internal budget we use to actually move the project forward
  • Planning Budget - the budget we use for planning and budget requests 
Calculations:

1. Base Estimate = summation of all the resource costs you need for the project (eg Labor, Hardware, Software Licenses, Conference and Travel, Support and Sustain costs, Implementation and Training Costs)

2.Base Budget = Base Estimate + Impact of Known Risks (see below how to estimate)

3.Planning Budget = Base Budget * Unknown Risks/Contingency Factor (see below for rule of thumb)

How to estimate the Known Risks

1.Analyze the risks you identified and determine which are related or dependent to each other (if one risk happens - the other will happen too) and classify them into risk groups

2. For each risk group identified - estimate the dollars it would take to recover the proejct or the business if the risk happens * probability of it happening (there is a more accurate way that includes impact - talk to me if interested) . Note - if the probability is > 50% - then it is an issue, not a risk.

Sum the resulting dollars
  
How to estimate the Unknown Risk Factors/Contingency Factor - this is more a gut feeling based on experience or parametric analysis of historical projects

If your gut or experience is telling you that

1.There is a low probability of unknowns - add 5-10%

2.There is a medium probability of unknown - add 10-15%

3. There is a major probability of unknown - add 15-20%

 Sum your numbers.

Tuesday, October 5, 2010

The Project Management Circus: Act 1 - The Tightrope Walker

I have heard several people in my career say that project management is easy - just give someone a project, resources and a goal and all he has to do is create a plan and monitor it to completion.

This is similar to what I hear from my co-spectators when I see a circus.

Truly, Project Management can be like a circus - in more ways than one and the performers are the project managers.

Take the tightrope walker as an example. What does he need to do anyway? He only needs to walk from end to end - how difficult could that be? Let see...

A tightrope walker, like a project manager, to succeed in his endeavor, would need to

a)know first where is his starting point - including information about how high he is from the ground, is there a net below him, how strong is the post he will stand on before he begis the walk, what is the length of his balancing pole,  how hot the spotlights can be, etc... - much like project initiation

b) know where his end point is and what is the definition of success (eg making it to the other side alive maybe in 5 minutes), what resources does he has to reach the other point (eg does he have a pole to hold on to and use as a balance), how many steps would he most likely need to take and how much can he trust his resources(eg his rope quality, his pole quality or the net quality if he falls). At the same time, he must know the pace he needs to take and how to take the steps - much like planning, contingency allocation and resourcing

c) know how to traverse the rope and keep his balance ensuring that he checks at each step whether he is on the right track or not. He must also know what to do when something goes wrong along the way(eg an ant is biting his armpit - sometimes called management pressure - or when his rope starts to shake because of a sudden wind gust - sometimes called sponsor wind) - much like project monitoring and control

d) know what to do when he gets to the end - if he gets to the end - including putting the pole down first (let go of resources), ensuring both his feet are really on the other end and raising his arms and waving to his adoring crowd - much like project closure and team celebrations.

Easy you say? Maybe...up until you are truly the one walking the rope.

Sunday, September 19, 2010

The Beauty of the RACI

The RACI chart is a standard document in most projects and I would say that it should be a standard in ALL projects ..but what is a RACI chart anyway?

RACI is an acronym and different organizations have different takes on what each letter means and that is why as a project manager, you should be aware of the standards of your client's company with regards to a RACI chart - take the time to ensure you have the right definitions because it can cause confusion later on. It is usually created when a project has just been conceptualized.

Typically RACI stands for Responsible, Accountable, Consulted, Informed. In other organizations, it can mean Responsible, Approver, Consulted, Informed or even Responsible, Approver, Coordinator, Informed. Whatever it can mean, it always answers the need to know who are the people responsible in defining and delivering the project and what is their role in EVERY task in a project. Most RACI chart requires there is only one R for each task or only one A for each task if the A means accountable - a good practive to have.

I recommend having a template of all the possible task that a project can take vs lumping them into generic work that may cause issues later on. The template can then be "customized" based on what a project requires. Remember - a task that says "complete the design document required for all data interfaces" is much more trackable and thus controllable that a task that says "complete design documents".

What is the importance of a RACI when you have a solid, trustworthy team? Each project is unique and in my experience, there is always room for assumptions and one assumption that team members usually make is that if the task is unfamiliar to them - then it might not be theirs and will taken cared of by another team member. Another situation is when the task can be performed by more than one person in a team - you can either have a case of two people doing the same work or noone doing the work.

By having a RACI chart from the start, you ensure that each person knows their role, the extent of their role, what they are expected to do in each task, if any, and how they relate to other people and their roles - a perfect recipe to prevent roles and responsibilities issues later on.

Friday, September 10, 2010

The Great Differentiator

I was asked today by one of my team members the following question - "what makes a great project manager?" Is it his ability to consistently deliver projects on time, on budget, in scope, with quality and with full user satisfaction?

I said "All those qualities make a project manager but not a great one".

A lot of project managers can claim all those in all his projects and I would argue that if the KPIs for a project manager are simply doing all these, he has but achieved the basic expectation of a project manager.  Every project manager, or those who claim to be one, must strive to AT LEAST do all these.

The great differentiator in my opinion between the good project manager and the great project manager lies in HOW he executes his projects to achieve his objectives - his leadership and people skills.

A project manager can deliver a project on time, on budget but he did so through intimidation, fear or extreme politics. A project manager manager can deliver his projects on time and on budget but he failed to nurture and sustain productive relationships within and outside of his team in the process. He could consistenly deliver his projects on time, on budget and yet at the same time - consistently breed distrust and disloyalty by claiming all the glory to the dismay of his team.

At the end of the day - what makes a great project manager? It is the one who can consistently deliver his hard deliverables through excellent leadership and people management skills.