One Page Project Estimates

The questions this post is providing an answer to are:

• How can a project manager provide visibility to his / her stakeholders when he / she wants to pitch to them a new project? 

• How can he / she highlight the risks associated with staffing and estimations and play with just a few variables so that risk is brought to an acceptable level?

The method (and its associated Excel-based simulated model) is intentionally simple, its goal being to have the outcome fit on a one or two page sheet and keep the number of variables low so that iterations are easy to make. It does not aim to provide an accurate representation for the risk nor to be used when the required precision is high.

I decided to write this post few days ago, when reading this article [Harvard Business Review] I realized that, in many ways, I have been proceeding in roughly a similar manner when providing high level estimates for my projects.

For the document that exemplifies the method I used, I kept the same example, the book store, for simplicity. Please note that:

• Numbers in the example are totally random

• This is a simplified model, designed to draw high level conclusions, and not a project management tool per-se. The aim is to fit all the information on a single sheet of paper, mostly communication and quick iteration purposes. Here is how:

 

Step 1:

• Fill the "Budgets" column with the main features of the project.
• In the "timeline" section add your estimation in terms of total headcount that you expect to have working on each specific feature. 
• In the "confidence" level add your "gut-feeling" estimate on how accurate your estimation is. In the simulation, the duration / budget will be considered to take somewhere between:

• Min: confidence% * estimation
• Max: estimation / confidence%, thus a a 50% confidence will lead to Min of 50% of the men-months needed and a Max of double the men-months needed, thus prolonging the time needed to finish the work.

Therefore, padding the estimations or taking extra safety precautions are not recommended.

• In the risk level add color coded where the uncertainty is drawn from (technology, backlog (scope), or management-related unknowns like external dependencies).

 

Step 2:

• Fill the resource breakdown in the second sheet of the document - this shows how you plan to allocate staff to the project. First start off with the initial breakdown (the one that came from estimating each of the features from the first page)  
• Look at the available resources and see how many people you can 100% commit to allocate according to the resource needs.  Then compare to the resource needs and add fill the "Min availability at ramp-up" column.  
  

 

Step 3: 

Evaluate the results - every time you press CTRL-S, a new simulation is performed.

Look at the basic simulation for resource availability:

The model is very basic. It takes into consideration the resource needs and the initial allocation probability and then randomly adds headcount to try to catch up with the needs. It assumes that, once a resource is allocated it is not deallocated until the end of the project. The basic idea is that staff may not be available in time (due to assignment to other projects or inability to recruit in time)

Look at the following section of the first table:

• In the green square it shows how much resource buffer you have (or you need to recover from somewhere - if it is a negative number).

Look at the execution simulation results:

The most important line is the DEBT MM. This shows how much you need to recover (negative numbers) or have the capacity to be ahead of the plan (positive numbers) on a monthly basis.

 

Step 4: 

This is the most important step - iterate and play with the numbers:

• Check what needs to be done to improve your estimates and what would be an acceptable confidence level in order to start the project.
• See what can be scheduled earlier in order to use the extra resources that you might have in the beginning and reduce the risk towards the end of the project.
• Play with the resource plan - after you run the simulation with the initial estimates, add / remove staff to each line to see how that will impact your buffers. Find a resource plan that you and your team feel comfortable with.

 

Step 5:

As time goes by, update the excel file with real data and see how your predictions match the reality. Don't forget that this is just a road-map simulation and a proper Agile process should be followed with the team.

End note:

Please always remember that this is a model, it is designed to help you ask yourself questions. It is simple by design because adding more variables would only make iterations cumbersome and relations between data points harder to grasp. Use the model to express to your stakeholders what you have in mind and identify some optimal resource and estimation targets that need to be met in order to proceed safely ahead.

If you need more depth, play with the formulas and add more data points to the model. If you have any questions, please ping me as well. I'd love to discuss your findings and your ideas on how to pitch and estimate risks more clearly, preferably on a single or maximum two page document. :)

Agile Project and Portfolio Management for Business Projects

Traditionally Agile is recognized as a software development-specific set of methodologies. The Agile Manifesto, the document that defines the pillars of the Agile movement, seems to inexorably link it to software teams. But is Agile so specific to software? Can those principles be applied to a wider range of initiatives? What if the “working software” wording is rephrased as “tangible value”?

1. Some problems Agile promises to solve:

• Things don’t seem to finish as there are too many threads in parallel. Lack of visibility, streams of emails to ask for basic questions and a general feeling of insecurity and lack of progress.

• “Business as usual” – process work, role based, without a clear understanding of the final objectives. Not much motivation. Fixed roles, "not my job".

• Hard to squeeze in change initiatives due to pre-approved budgets and plans.

2. Paradigm shift:

Everything we do is a due to a change we want to see in the system.  Thus a clear, time-bound and resource-bound, measurable result is desirable.  Ideally, everything should be transparent and people commit in group to the goals. It is OK to change roles, as people that learn new skills and extend their responsibilities are more motivated, reliable and happy. Thus we can approximate that everything we do is either a project or part of a project which we plan and we allocate resources to. All these initiatives form a portfolio that needs to be managed. As objectives shift in time, everything becomes subject to challenge, discussion, and prioritization and, of course, cancellation.

Hierarchical backlog in which we link all projects to strategic objectives and areas of responsibility.

(Suggested first step: write down business goals as a hierarchical structure, with areas and owners. Each project is then linked to a specific goal. By default, the area owner becomes either the default project manager or the portfolio manager for his group of projects. In the picture above, we used Jira with the Structure plugin to organize the information.)

3. Crossing the bridges:

Agile distilled:

A set of principles on how to respond to change and maximize value creation.

Agile manifesto for non-software related projects: 

"We are uncovering better ways of developing software delivering value by doing it and helping others do it. Through this work we have come to value:

o Individuals and interactions over processes and tools

o Working software  Maximizing value over comprehensive documentation

o Customer collaboration over contract negotiation

o Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more."

Agile Methodologies Distilled: 

Practices to support the values. If values make sense and you implement practices that support them, you are already Agile. Is there anything inherently contradictory to managing in an Agile way any type of activity or task? 

What Agile is not:

• A software-development only methodology that is completely opposite to the traditional way of managing projects. 
• For kids, youngsters and pet projects.
• For unconventional start-ups only.
• Something new that has not passed the trial of time.

And, of course, the set of associated myths: 

• Agile practitioners do not plan. 
• Agile does not offer any guarantee nor commitment to results.
• Agile can only be done with a physical board, post-its, endless meetings and a significant dose of nonconformist.  
• To be Agile requires for everything to be changed.

All in one paragraph:

Agile is a philosophy, a set of lenses through which we see the world. The supporting practices feel natural and safe in most of the environments, but they do require a certain dose of sustained caring for people and discipline to implement them.

3. Agile Simple Portfolio Management for non-software teams.  

Scrap the “sprint, Agile, scrum, epics, feature, and retrospectives” terminology.  They might scare people away. Use the common human language, explain as if for a friend. Then just do it: call the meetings, follow the process, plan, ask the questions.

Jira Agile Project Board

(Suggested second step: together with the owner, define and agree on a backlog of projects that would help fulfill the business goals. There's no need to plan everything upfront. Rough estimations are enough, just to understand the business value, align on vision and on cost. Minimize the amount of project in progress. Re-discuss value and re-prioritize every iteration.)

Ok for planning, monitor and control, but why the continuous improvement? 

There is a common misunderstanding with S.M.A.R.T - The Achievable. How do I know that if I receive a business goal of "increasing the business value by 15%", the 15% is: a) realistic goal and b) the best that can be done. 

Let’s introduce continuous objectives and continuous improvement. It is OK to start with the worst process in the whole world. It is not OK not to improve everyday. When '"New Balance" built their first sport shoe in US to compete with the Chinese-made Adidas and Nike, they first built the most expensive sport shoe in the world. Then they improved. Now they are competitive. The question is: how can we improve, no matter how good we perceive ourselves to be. Compete with ourselves, not with the objective. 

For continuous improvement, we need data: track performance with charts, flows, timing. Get numbers. Agile metrics are there to follow and spark continuous improvement and retrospectives. Everything that is done goes through the process, otherwise you cannot get the full picture.

Jira Personal Taskboard

(Suggested third step: once a project is set to WIP, work with its team to break it down into tasks. Check that the tasks indeed conform to the vision and that the vision was properly understood by the team members. Follow-up. Build up on their vision as well. )

4. But how do I get control and confidence?

• I want my Gantt chart - yes, here it is: the road-map
• I want my project status reports - yes, here they are, the project metrics
• I want my change requests - of course, let's prioritize for the next iteration.

Jira-provided burn-up chart

(Suggested fourth step: Follow-up the metrics and hold retrospectives. Present the metrics to the team (hold the mirror) and check how people are satisfied with the results of their own work. Brainstorm for how results can be improved - there are specific Agile practices for this).

5. Additional notes:

Jira is a great tool for several reasons:

• With the help of the Agile plugin, it is very easy to understand how Agile works. 

• As it is a flexible workflow-based tool, it can be extended much beyond the task / defect / project tracking. We have defined custom workflows and use the same plugins for repetitive business processes, like travel, recruitment and purchases. It comes very handy as it is a one-stop point for almost everything we do, decreasing email communication and providing visibility and tracking for almost every activity.

• Although slightly difficult to customize for a fist time user, there is a lot of documentation out there, forums and people whom can be asked for support.

HAPPY MANAGING! :)

The Leader - A Perspective And An Aspirational Model

What the leader is and does:

• Attention to details & depth of understanding - relentless pursuit of perfectness in any deliverable. Seeks for beauty, concision, simplicity, clarity. Is not satisfied with default answers and quickly spots assumptions, both in his own reasoning and in others.

• Autonomy & entrepreneurship - finds work for himself and his team. Helps his team develop their autonomy, through clear roles and responsibilities. Holds people accountable, thus he is perceived as a delegative and empowering leader. He is self-motivated by growth and achievement and tries to secure a bigger impact for himself and for his team.

• Integrity - speak the truth, even if inconvenient . Does not take shortcuts in his work, even if sometimes it means taking the difficult path. Does not procrastinate. Does not hide anything. Commits and assumes responsibility for the results, either good or bad. Does not seek to blame others.

• Collaborates for results with his peers and his manager. Manages transparently and brings tough subjects to the table confidently. Looks people in the eyes. Negotiates for win-win. Recognizes his team interest.

• Curious and always learning - sees every interaction as an option to learn something new. Passionate about at least one field related to game production (programming, game design, project management, art)

• Exceptional communicator - synthesis / analysis skills. Presentation skills - both in writing and verbal. Clarity and vision.  Adapts to his / her audience, up, down and across. Is able to express complex ideas in simple terms. Does not use meaningless wording. Seeks for beauty, concision, simplicity, clarity. Understands and assumes what he says and brings value to the communication.

• Finisher - is capable not only to propose and start new initiatives, but also prioritize among different ones. When committing to a course of action, drives it to completion.

• Results driven - keeps things simple by focusing on clear, measurable results. Understands that "implementation matters" and does not trade integrity for short-term gains.

• Energy, optimism, social skills - people feel energized when he is in the room. Instills positive energy in the team. Cheers people up. Is well educated and knows how to behave in social situations (including meetings). Inspires confidence and expertise.

• Visionary, strategic thinker and tactician, all in one - is able to think long term, define goals, chart plans and inspire people. Is able to zoom-out and zoom-in and work at different levels of detail.

• Inclusive leader - is humble and self-confident. Relies on people and understands roles and responsibilities. Manages to make people feel accountable for their own results. Respects people and their point of view. Is able to drive the discussion towards rational arguments. Is able to call meetings and bring difficult subjects to the team for finding solutions.

• Disciplined pursuit of daily activities - the team knows what to expect from him, he has a set of rituals and a transparent schedule.  Always on time, always predictable. Holds 1:1s, retrospectives and is constantly for lookout on how to improve processes.

• Systemic view - Fixes the root causes, not the symptoms.  Has a systemic view of cause & effect and understands feedback loops.

A leader might be:

• Project management expert or agile practitioner

• Passionate  about engineering, product, design, quality, management, …

• Motivated by power/impact and/or achievement

• People oriented or product oriented - the things that matters are: people feel they are led to victory, they feel the project is good for their careers and that there is always something new to learn and improve.

• Good public speaker

What the leader is not:

• People pleaser (up-down-across) - These leaders are reluctant to take unpopular decisions and be open. They create an unhealthy environment of low performance and comfort around them, based on social networks and office politics. Also, they tend to "buy" support instead of challenging the teams for results.

• Syndicalist leader - These leaders will always create a rift between the team and the management, pushing towards antagonism instead of alignment.

• Passive aggregator of information - the leader adds value to any communication, by being able to summarize it and lead meaningful discussions with his peers, managers and team. He understands the requirements, the language, is able to extract the substance and act as an independent hub of knowledge.

• Tyrant - The opposite of syndicalist leader. Disregards his team and is willing to take easily decisions that  affect his direct reports (salaries, free days, maternity leaves cuts, etc… )  in the name of company profit.

• Non-committal and non-responsible - discusses people instead of results. Invents problems and likes office drama. Comes to rescue when conflict appears. Does not take responsibility for failure.

• In only for himself - people around him and their successes don’t matter. All he cares is his career or proving his point of view. Focused on showing how good he is and how the results depended solely on himself.

• Opaque to others ideas (up / down / across)  - not be mistaken for self-confidence. Self-confidence means exactly the opposite: showing vulnerability, willingness to learn, involving other people, asking for opinions.

• A leader in the vacuum - willing to sacrifice collaboration and integrity for quick wins. Does not care about the impact of his actions on the future, people and projects around him.

• Complainer - sees problems and possible improvements but fails to take action to remedy them.