Deadlines

Deadlines, target dates, call them what you will, but every project has dates and deliverables. When deadlines are tight, I often see underlings commit to a date, and when that date arrives, they quick add the infamous caveat “Monday… end of day Monday”.
Monday becomes EOD Monday, which then becomes midnight, which then becomes Tuesday morning and so on.

A company should have a unified policy as to what due dates mean. The 1st, doesn’t mean end of day, it means that morning. It means the deliverable is ready for demonstration, testing, release or whatever the case may be.

Identify the Owner

You’ve heard the saying, “Too many Sith Lords in the Command Ship”, I think you earthlings have a similar saying of “too many chefs in the kitchen”.

Collaboration is great, and should be a natural part of your organization’s culture - but issues and confusion will arise if owners of areas aren’t clearly defined.

Whether it’s fighting a crisis, issue resolution, routine tasks, domain areas, to projects - there has to be ONE owner. Otherwise it’s unclear where information ultimately needs to flow up to, and what the chain of decision making needs to be.

Is your technical staff on-call? What if that pager goes off, but it’s not in that persons particular area of ownership or expertise? The person on-call is the owner - the owner of the alert, and they have the power to rope in the subject matter experts needed, and/or the owners of such areas. Ultimately the resolution of that alert is theirs.

On a Project, there has to be a single-owner. Don’t confuse this with sponsors and supporters of the project. The owner of the project is ultimately responsible for getting the project done.

Do you have a Database team? There has to be someone who owns the maintenance plans, data architecture, schema design, database change policy and processes, etc… It doesn’t mean they have to come up with all the ideas, and all of it could be the result of the team collaborating on what the best practices need to be. And it doesn’t mean they have to do all the work. But the owner is responsible for making sure that that collaboration occurs, gets documented, and somehow enforced.

When fighting a business crisis or a technical one - make sure the owner is clearly defined. Otherwise people are going to naturally float decisions up their management chain, it won’t be clear whose making the decisions in the first place - so you get this decision confusion that results in latency as everyone tries to sync up on who decided what.

Productive vs Active

Now and then I’ll see military units such as squadrons of Storm Troopers scrambling around suspect rebel planets, or see our Software Development staff feverishly coding to make the UI look cooler.

But here’s a question that I pose to Executives, Management, and Product Managers - is such staff being productive, or merely active?

Frantic Work May Feel Productive, but is it?

To feel productive often people go into a frantic work pace, they’re motivated to get things done, and they want to bring value to the organization and themselves. But just because they’re moving quickly, firing off a ton of emails, defragging hard drives, whipping rebel prisoners, and experimenting with some new tools doesn’t mean they’re being productive.

This sort of activity should be allowed, the reason people do it is it’s a way to mentally recharge. Reasons may very, but for example they might have come off off a long and intellectually intense project, or when dealing with a particularly complex problem they need to walk away from it and focus on something else for a bit so that they can come back to it with a fresh perspective, and emotionally it helps them recharge (being able to innovate with new technologies, or tackling some no brainer tasks to feel they got a lot done, etc…).

The Difference

But, from a people management perspective this type of activity needs to be controlled as it might not be productive. The difference is productive activity is prioritized work; it’s an established effort that is aligned with the organizations mission and stated goals, has time allocated for it, and should also be line item on a person’s performance plan.

Allow It - But Control It

So, stick to the 80/20 rule here - make sure that the productive time for your people is at 80% or greater. If innovation is important in your organization - make it part of your mission and state goals, that way your allocating the time for it.

Making an ROI Worksheet

Do I build another Death Star, or a few more Star Destroyers, invade the rebel base on the planet of Pladoon, or do I upgrade our EMS (Empire Management System)?

Well the answer to the above are based on vision of the Empire, strategy, and ROI.

Periodically you should be holding a meet either once a month or once a quarter, and evaluating new projects that are being proposed vs what is already in the pipeline. You want projects that are aligned to the goals of the organization, but at the same time you want to prioritize on those that give you the biggest bang for the buck (aka ROI).

As a Project Manager, or Manager of the PMO Dept, when presenting the options you need to summarize all this in some cohesive manner that allows Executive management to quickly assess the options. They’re not going to have time to read all the thorough documents behind each proposed project.

This is especially true if you’re kicking off roadmap planning for the first time in your organization; so the goal here is to make decisions based on information vs a gut feel.

Enter the ROI Worksheet

Summarize all your Projects into the ROI Worksheet as exampled:

* Click on above image to view

Use whatever columns give you actionable information to base a decision on. Some things to keep in mind:

• Any return is just Potential at this point. After the project is complete you want to compare actual return vs the predicted/potential.
• It’s ok if you’re at a stage in your Organization’s PMO where doing hardcore ROI analysis isn’t a strong skill yet. So if you don’t have hard numbers, use a 1-10 scoring system when needed. The idea is you need the ability to numerically compare one project vs another - even if some of that data is subjective.
• Strategic Value will never be something you could compute, but it is an indicator of how well aligned the Project is to your Organization’s goals.
• Ease of Actualization is important to consider. Even though a return is potentially high, if the Actualization of that Return requires extremely skilled management to pull it off, that’s something to consider. Likewise, some Projects have a return where the ROI is immediate and self actualization - which is very attractive as it doesn’t take much work to get it.

So whether you give a score by consensus, or through some formula, Executive Management can now sort Projects by score or filter for Projects that score a certain minimum amount.

Unintended Consequences

Every action has predictable consequences, but they also have unforeseen positive or negative consequences.  Let us review a few classic Earth examples that everyone can relate to:  bike helmet laws.  These laws actually caused accident frequency to increase as drivers presumed the cyclist was experienced and cars would drive closer to riders wearing helmets.  Another example is child-proof safety caps on drug bottles.  They actually increased children’s access to drugs because seniors would leave the caps off, as they found them too difficult to open.  Adults would also presume the child-proof caps to be so safe, that they would leave the bottles where children could get them and of course children would defeat the safety caps.

These simple examples illustrate that while an idea may seem appropriate and the consequences will be beneficial, there are unintended consequences that can occur.

In the business world, any idea can be implemented with a presumed consequence.  Care must be taken to study the actual results and be prepared to deal with it.  Unfortunately, no manager wants to champion an idea, only to admit it was a partial failure and then have to deal with the consequences.

When a project is started, the Project Plan should include post-ROI analysis so any unintended consequences can be discovered.  To be proactive, the Plan could also contain a post-rollout tweaking phase so resources and time can be set aside to address further issues.

80/20 Rule

As the rebels found out, a Death Star doesn’t need to be 100% complete, to have basic functionality.  Large projects can become bogged down due to their sheer size, or scope creep can rear its ugly head and cripple a project’s time-line.  In order to combat these issues, the 80/20 rule can be very useful.

History:  The Pareto principle, AKA the 80-20 rule states that 80% of the effects come form 20% of the causes.  It was originally conceived when an Italian economist noted that 80% of income went to 20% of the population.

This can be applied to almost anything.  80% of your sales come from 20% of your clients.  80% of your results come from 20% of your employees.  It can also work the other way, where 20% of your effort, produces 80% of your results.  For example, if you spend 10 hours writing a college paper, 2 critical hours of time produce 80% of the results.  The remaining 8 hours is spent on the last 20% of your paper.

In project management this rule can be applied in various ways.  Spend 20% of your time to build software that has 80% of the features you want.  Attempting to squeeze in the last 20% will take an additional 80% of your time.

When planning any project, consider what are the core results that you want, the most important 80% and leave the nice-to-haves or remaining 20% out.  This will enable faster project completion times and also make sure resources are being spent as efficiently as possible.

This also begs other questions:  If 20% of your people are producing 80% of your results, what are the other 80% of your employees doing?  If 20% of your day produces 80% of your results, how can you maximize your efforts so you don’t waste 80% of your time going after the 20%?

Excessive Upward Decision Delegation

Many organizations suffer from excessive upward decision delegation, where you cc your boss, and he cc’s a General, and he cc’s a Sith Lord who can then rope in the Sith Lord of an adjacent team and then work all the way down to the target team that work is requested from.

Why does this happen? Well, if they’re Jedi scum, enough said. So called ‘experts’ say this is a result of management who tend to overturn decisions frequently, therefore staff feel they need to constantly get the final decision by delegating up. The second reason they point out is they may not know how to do the job – in such cases we electrocute such staff.

There is another reason however; it’s the result of unidentified roles. If you bring together a collaborative team of experts who are all Sr rank, and it’s unclear who ultimately has to make the decisions. When bringing together a group of people to work on a project you have to clearly identify the following roles (or what role each person has):

Responsible/Owner: The *ONE* person ultimately responsible for the project. They are empowered to make all the decisions in the end. It’s effectively the project leader. In small projects, the owner is often the person that also does the bulk of the work, but not always. The Owner is responsible for getting the project done, either by doing things themselves, or making sure that they have the people they need to get the job done.

Approver/Executive Sponsor: Someone who is signing off on the project, and empowering the owner.

Supporters: These are people in the team that have active tasks and portions of the project to complete. They do the work.

Consultants: Subject Matter Experts: they provide advice, direction, and guidance based on their experience and expertise. But typically don’t have much active work in the project.

Informed: People who need to be kept in the loop. They may be managers of teams that will be impacted by the project, end users, training teams, etc… They don’t have much say in the project.

How Planning Crushed the Republic

Call it a Project Plan, or an Action Plan, the fact remains that as much as the Jedi Council wants it to be true, belief in the force is not enough to achieve success.

A Plan is the fundamental vehicle towards success, it forces you to think out very thoroughly all the steps and dependencies that are needed to achieve a goal.

Of course that’s obvious you say – yet I feel a great disturbance in the force when it comes to planning, and it’s the result of people not doing it.

Sure, using the dark side of the force was an advantage we leveraged in order to take control of the universe and form the empire, but think about it. How did we pull off uniting all the planets under the banner of the Galactic Empire? It didn’t come from luck, and it didn’t come from hoping and merely trying that it’ll work out.

It came from an extremely complex project plan with all kinds of linked dependencies. From financing the droid armies and clones, to the infrastructure needed to build all the star destroyers.

But a Project Plan does more than just think things through, it’s a communication mechanism. It clearly communicates expectations so that there’s no doubt as to where things are and where they’ll be, it also clearly identifies who is accountable for what. Without the Plan you’re relying on vagueness, and thinking like an incompetent Jedi who hopes that things will just work out. You have to tag people with what they’re responsible for, and when you need it by.

And if they don’t come through… well they either get fed to the Panna Monster, or get a dose of electrocution.

In very complex plans you’ll need a tool like VS (VaderSoft) Project so that you can link up dependencies, but in most cases smaller phases can do with a simple VS Word or VS Excel document that has a simple table consisting of:

ID	Task	Responsible	Target	% Complete
1	Fuel All Death Stars	Lord Kaan	05/02/9820	98%
2	Board all troops	Ludo Kressh	05/03/9820	10%

There’s a few more columns you can add if you feel useful such as a “Status” column to indicate workflow status (development, qa, release, etc….), a “Notes” column for comments, and a “Original Target Date” so you can flush out incompetence and quickly highlight if something is offtrack (and thus know who needs to be fed to the Panna Monster or be electrocuted).

Getting a grip on priorities

Often organizations can find themselves under a mountain of requests and they can’t see the forest from the trees. It’s overwhelming and management doesn’t even know where to start – so they don’t, and what ends up happening is the organization becomes short sighted. Priorities are based on today’s biggest issue, efforts are directionless, all requests are escalated all the way up the management change, and whoever yells the loudest wins.

Vision

The source of the problem stems from lack of vision, and the corporate objectives that come as a result.

To get a grip on priorities you have to start with having a vision – even if it’s just a simple one line statement of where you’re aiming at; it’s the step to narrowing a blurry view into a focused one by getting everyone pointed in the same direction.

Corporate Objectives

From that vision, define your corporate objectives or goals. These are specific, measurable, achievable, realistic, and time bound (aka S.M.A.R.T goals).

For example:

- Increase delivery time of star destroyers by 10% over the next 12 months.
- Decrease rebellion uprisings by 5% over the next quarter
- Destroy 20 rebel planets by end of year

Nested Objectives

As a corporation (or empire) you only need 2 to 5 of these; each organization underneath you will have nested objectives that support your top level goals. And now that these have been defined, you have the various projects that support each of these objectives.

Alignment of Projects

So go back to your endless laundry list of requests, priorities, enhancements, and projects and first determine which ones are supportive of the goals in your organization. If they do not support the goals, then you have to simply put them aside – even if they’re good ideas.

Executive/Sith Lord Sponsorship

What’s left requires evaluating if projects have an executive/Sith Lord sponsor. If a project is unsupported, you’re taking a huge risk by investing any effort in such a thing. There may be ROI, and it may support the goals, but without executive sponsorship the chances that the project will be successful is highly doubtful. This is because the project will then hinge it’s success purely on the ability for all the teams involved to function by consensus; and of course all serious projects come to serious forks in the road where differences in opinion will deadlock the project – an executive sponsor can make those tough decisions.

Another reason why executive/sith lord sponsorship is needed is because if each team involved doesn’t have their portions of the project as deliverables as part of their performance plan, there’s no incentive for them to put in the effort. In fact, putting in any time, takes away from projects they are on the hook for.

Lastly, if an executive sponsor/Sith Lord finds out you spent a large amount of galactic credits and it didn’t pay off, now you’re in deep water with no one to support you. A Sith Lord is liable to feed you to a Panna Monster in such a case.

ROI

Ok, now you have a list of projects that are aligned to the goals of the empire, and have the executive/Sith Lord sponsor to back it. You still will have a list of projects that require more resources than you have, the next step is to evaluate the potential Return On Investment (ROI).

The ROI comes in the simple and tangible form of quantitative, and the difficult to measure qualitative. Projects that have more quantitative ROI are the ones you want to go after, as they’re easier to measure the actual results (increased revenues, cost savings, etc…). Versus the qualitative ROI which is almost impossible to measure, and even more difficult to actualize.

Of the quantitative ones you want to evaluate the actual potential ROI, how easy it is to actualize that ROI, and how you’re going to actualize the ROI.

Here are some things to think about. If you reduce the time it takes to do something, what’s the return? From a financial and quantitative perspective the answer is none.

The return is when you see the impact to the bottom line – now saving time definitely has qualitative benefits, but the point here is as high as an ROI is, you need to assess how capable your management organization is at being able to actualize the ROI.

E.g. does it entail reducing overhead, reducing headcount, restructuring the organization, etc… Say that project can save $50M, but costs $100M – your ROI 50% in one year. Compare that to a project that costs $100, and saves you $100/yr, this has a 100% ROI.

So keep a relative perspective in mind as well; smaller projects may not have the huge total numbers of bigger projects, but their ROI is much easier to actualize and therefore lower risk.

The bottom line is you need to rank projects by ROI- giving extra points to projects with more quantitative than qualitative, giving extra points to the ROI ratio, and extra points to ease of ROI actualization.

You can only calculate ROI if you have the (I)nvestment portion, so you pick off the top x projects until all your resources are booked for whatever timeframe you’re working with.

In Conclusion

Using this formula will help you get a grip on priorities and get your organization executing on a path that will allow the organization to achieve its goals.

Problem Statements - What are you trying to solve?

Often in meetings, whether it’s a brainstorming/vision meeting, product management, or for the proposal of a particular project – the support for an initiative is based on what someone wants, i.e. the target is based on the feature itself.

This is incorrect thinking, and I use the dark side of the force to punish anyone who continually thinks so narrow minded. You have to focus on the problem – all project kick off meetings should start by stating the problem (that needs to be solved), or task #1 is to identify it.

The Problem Statement should be on the header of all project documentation as it is your guide to solving it. It’s too easy to get excited about features and capabilities; for example say you bring the proposal of “we want to build a laser cannon.” You can spec it out, and it can be built – but what if the problem was merely for security forces inside the ship to take down Jedi’s who have penetrated the outer defense and are already inside? One, not only would a laser cannon blast a hole through the ship, but secondly Storm Troopers wouldn’t be able to feasibly lug something that big around.

See, unskilled managers will ask the weapons development team to build such a thing – but it doesn’t solve the problem. Don’t ask for the tool; ask for the solution. And the solution is a combination of processes, tools, and policy.

For example, say the software that controls the doors to the docking bays asks the user to ask the pilot a number of questions to ensure everything checks out – and you have an issue where there’s been too many unauthorized landings (usually the resistance trying to get inside); so the management team thinks well let’s just highlight things in red, and do popup warnings on the screen to add extra emphasis.

But if the docking bay operators are being scored on how fast they can get ships docked, there’s no incentive for them to follow the warnings.

So the true solution involves process; by making sure docking bay operators are adequately and periodically trained on docking bay policies, that managers coach supervisors on how to coach those operators, and that managers have exception reports to highlight those users that are not within the tolerances of ‘normal’. You would also augment the staff’s performance appraisals to include adherence to the policy as a performance metric – otherwise if bonuses/raises aren’t in sync or supportive, you’re inadvertently MOTIVATING people NOT to follow the policy.

Now your solution is end to end complete by having software guide the user, but having management enforce the policies. All of which has been defined by the Problem Statement.

Always ask yourself: What are you trying to solve.