Estimating is the act of predicting the future based upon imperfect data. Most of us rely on estimating methods (top down, bottom up, analogous, function points) and a flurry of math and spreadsheets. But no matter how much science we try to bring to our estimates, there will always be a place for experience, judgement and good communication. Here are some tips for going beyond the math.

Have you confirmed what your project is expected to accomplish? Are you trying to deliver a quick win to build momentum or overcome the objections of a dubious stakeholder? Are you trying to deliver at as low a cost as possible, even if this takes more time? Are you trying to optimize time and cost while delivering a high quality solution (probably)? This is a good conversation to have with the client or colleague that requested the estimate before estimating begins. Their objectives might surprise you.

Do you have a firm understanding of the scope of the project? What is the technical solution that is being delivered? What services are expected to be provided; who is delivering the training, the testing, the documentation…?

What delivery approach are we taking? Are their multiple releases? Are there multiple phases; a planning phase, a design phase, a build phase, a testing/training/cutover phase, a post-go-live support phase…? Is it appropriate to include all of these releases and phases in your estimate or not?

If you are developing an estimate for an external client, then consider the contractual requirements. What are the pricing terms; fixed price, capped, time and materials? Are there any milestones at which we will re-estimate the project with better data? If any of these points are not yet agreed then make reasonable assumptions, and communicate them to the client.

Finally, before conveying your estimate to the requestor, remember to convey the level of confidence you have in the estimate. This allows the requestor to understand not just the estimate but also the level of uncertainty that exists, and the level or risk they need to manage if they rely upon your estimate.

Estimating is about math. But great estimating is about much more than that. Happy estimating!

I’ve spent over 25 years in the IT industry, mostly in project leadership roles. I’ve had the pleasure of working alongside many great leaders, watching their work up close. Successful leaders often possess great technical skills, a keen intellect, creativity and many other skills, but it’s their ability to foster a culture where teams can thrive that really matters. Here are some key principles that I’ve found to be essential for leading teams effectively in our field.

Success through the accomplishments of others. A leader’s success is defined by the achievements of their team. Great leaders know that their role is to support and elevate their team members. This means humility; putting the spotlight on collective effort not personal accolades. By focusing on the team’s accomplishments, leaders create a collaborative environment that encourages innovation and productivity.

The principle of ownership. Ownership is a cornerstone of effective leadership. True leaders take responsibility for both successes and failures. Ownership means internalizing responsibility rather than externalizing fault. When leaders embrace ownership, they inspire their teams to be accountable and proactive. This culture of responsibility drives continuous improvement and fosters a sense of pride in the work.

The power of agency. Agency is believing that you can always make a difference. Effective leaders never feel helpless; they always see a way to influence outcomes. This mindset is crucial in IT, where challenges can be complex and multifaceted. Leaders who demonstrate agency inspire confidence and resilience within their teams, showing that there’s always a path forward, no matter the obstacles. One trick when faced with a team-member who believes a task is impossible is to reframe by asking, “under what circumstances could we do this?”. This takes impossibility off the table and builds a list of obstacles which are often quite surmountable by a creative and openminded team working together.

Embrace servant leadership. Servant leadership is about putting your team’s needs above your own. Great leaders act as stewards, focusing on the well-being and development of their team members. This approach builds trust and respect, creating an environment where everyone feels valued and motivated. In the fast-paced IT industry, servant leadership helps maintain high morale and engagement, even under pressure.

Provide what the team needs. The primary role of a leader is to ensure their team has everything they need to succeed. This includes providing a clear vision, assembling a team of skilled individuals, ensuring access to necessary resources, and offering clear direction. Once these elements are in place, the best leaders step back and let their teams do their work. They monitor and adjust. Trust and autonomy are essential; micromanagement stifles creativity and hinders performance.

Entrepreneurship is hard. Having a great idea is hard. Throwing away great ideas and having better ideas is hard. Finding others to help you to develop your ideas is hard. Raising capital or bootstrapping is hard. Acquiring customers is hard. But the greatest challenge to face an entrepreneur is often “scale”.

As your startup approaches key milestones – the first remote development team, the first Fortune 500 customer, the 100th employee – you must change and adapt to new conditions or risk losing what you have built. What got you here, won’t get you there.

I recently read an interesting article by Jason Lemkin called “6 Key Signs a VP Can’t Scale Beyond $5m – $10M ARR“. It contains some pretty decent advice for entrepreneurs as they review and edit their leadership team to achieve scale. The article is written a little negatively though, so let’s reword it in a positive light!

Be organized. If you are small you can be both successful and disorganized. Your sheer force of will is enough to get things done. Plus your entire team lives in a single office/basement/garage so you can just talk to your colleagues. As you grow you will not have the luxury of being disorganized. You need performance metrics, project managers, CRM systems and capacity planning.

Hire great people. Hiring people is scary. Hiring people that are smarter than you is very scary. Hire amazing people that will drive growth and, if you are worried that they might outsmart you, work hard to elevate your own game accordingly. B-players will not get you where you need to be.

Companies compete in two markets: the market for customers and the market for talent. Compete equally ferociously in both.

Diversity matters. Hiring like-minded people can be acceptable or even desirable in the early days. Cohesion of vision can help you to focus. But as you grow you need to add people with new skills, different backgrounds and fresh, challenging ideas. A great hire can be very different than you. They extend your culture rather than simply fitting in.

Be OK with large numbers. As your company scales, the numbers can be intimidating. From 5 to 10 to 100 developers. From $1M a year to $1M a quarter to $1M a month. You need to be OK with this. Don’t freak out.

Distribute the team. It’s almost impossible to keep up with growth by simply hiring more people in your hometown. Your customers aren’t all in your hometown. The talent isn’t exclusively in your hometown. If you are based in North America or Europe its hard to maintain a good cost-base by restricting yourself to your hometown. You need to be OK with developing teams in other cities, countries and continents. You also need to be OK with the consequences of these changes: working in multiple languages, Zoom calls and decentralized decision-making.

Be OK if someone is hired over you. Sometimes the board or CEO will decide to hire someone over you. In their estimation, they need more horsepower to take the company to the next level. You were the best engineer reporting to the founder. Now here comes a VP Engineering or a CTO and you report to them now. Park your ego. Remember that you’re probably still the best engineer. Take advantage of your new colleague’s new energy, fresh eyes and strong skills. Don’t quit.

In this post I share the third of my top three learnings from art college.

Design is pervasive

The top-level design of any system has a pervasive effect on the design of everything within it.

Consider a modern North American city like Vancouver. The top-level design (or city plan) is that of a grid: perpendicular streets and avenues. City blocks are therefore orthogonal, consisting of straight lines and right angles. This means that the lots are orthogonal. The homes built on those lots tend to be orthogonal too. The rooms within those homes are therefore orthogonal. Even the furniture within those rooms tends to be orthogonal, exemplified by the right angles and straight lines of classic North American Mid-Century Modern design. The top-level design has influenced the design of everything within it – even at the lowest level.

Contrast this with the older portions of European cities. Built in a time before cars they feature winding streets that trace more organic forms on the map. Lots are irregular. Houses are often triangular, bow-fronted, crenelated. Rooms within contain bays, alcoves, circular features. The furniture of the period is more ornate and curved. Again, top-level design has influenced lower levels of design.

Application to Business

I am often asked to lead changes to processes, technologies and teams of people. The leaders that engage me recognize that things must be different. But the reason these processes, technologies and teams behave as they do is often defined at the top level: by the culture and behaviour emanating from the top. For example, if a leadership team wants their team to be less risk averse, they themselves should be less risk averse. Similarly, if the leadership team wants their processes to be followed more rigorously by their staff then they themselves must demonstrate consistency and discipline.

The top-level design of the system has a pervasive effect on the design of everything (and everybody) within it.

In this post I share the second of my top three learnings from art college.

Framing

Framing is the way you define the problem you are trying to solve. In industrial and product design the problem might be something like: how to remove pet hair from a carpet; or how to hold a single rose, beautifully.

How we frame the problem can unlock our imaginations. Conversely, framing can constrain and contaminate how we approach the solution. For example, if I ask you design a chair you will likely design something conservative and derivative. If I ask you to design a device for sitting, then your mind will open up.

Application to Business

In IT we often define the problem by describing business objectives (the why). That’s good. Then we write and approve a requirements document (the what). That is less good for two reasons:

1. The sheer size and complexity of the requirements document can create a can’t-see-the-wood-for-trees effect. We become so distracted by or rigidly attached to the requirements that we forget the objectives.
2. Too often the requirements aren’t actually requirements (the what). They are proposed solutions (the how).

To unlock the imaginations of our solution architects and software engineers we must frame the problem correctly. What problem are we really trying to solve? What is the why? What is the what? Let the engineers figure out the how.

More on reframing here, including the excellent “why they put mirrors in elevators” parable: https://hbr.org/2017/01/are-you-solving-the-right-problems

A few years ago I went to art college. OK, I didn’t really go to art college. Not in the cool jeans-covered-in-paint, Gauloises-smoking sense. I took a few courses in design at the Emily Carr University of Art and Design in Vancouver. I took the courses for pleasure but, surprisingly, I learned a few things that have had direct application in my work. In this post I share the first of my top three learnings.

Fail Forward Faster

Fail Forward Faster is a simple concept: it is better to rapidly design and build a solution for a given problem that to spend a long time perfecting your design before beginning to build. This is because your initial design will inevitably be flawed in ways that cannot be known when designing but that can be discovered quickly by building.

This lesson was demonstrated to us through an exercise. We had to build a structure capable of holding an egg one metre above the floor using dry spaghetti, string and masking tape. My group designed an elegant A-frame solution braced with a single guy wire. It was beautiful on paper. When constructed, the spaghetti bowed dramatically and our egg was not held high enough off the floor. We failed.

Another group built a chaotic, bendy Eiffel Tower. They began building quickly and added to their design on the fly to reinforce sections that bent too far. They succeeded.

Application to Business

We have similar approaches in IT of course. Prototypes. Proofs of concept. Iterative methodologies. Agile. But never have the benefits of an iterative approach been demonstrated to me so clearly. Want to convince your colleagues that iterative methods work? Grab some spaghetti, string and tape.

I have seen many business cases for proposed IT projects. I have seen few good ones.

Authors generally do a good job of describing the project, its scope and the costs. This is because authors are typically project managers or other IT leaders who are very familiar with project scope documents and budgets. Where they tend to fall down is in describing the benefits. All to often I see the following.

• “This project will improve efficiency.” – Too vague. Efficiency is often a code word for “we just don’t like the old system”.
• “Upgrading will improve reliability.” – OK, how much? What is reliability today? Why isn’t that enough? What will it be after the project is complete? Who will measure it? When?
• “There are huge issues with the current application.” – No hyperbole!

We need to apply the same discipline that we use when defining scope and costs to the benefits in our business cases.

Not all benefits can be measured in purely financial terms. That’s OK. In fact, the most compelling business cases are often based on non-financial benefits such as reputation enhancement, improved worker safety, or reduced environmental impact. But we are asking permission to spend real money and we should be clear about what that money will buy.

Begin by classifying benefits properly. Benefits are either:

• Monetizable – resulting in reduced costs and/or increased revenues;
• Quantifiable – resulting in measurable but non-financial improvement in some factor that supports the objectives of our organization (e.g., reduced lost-time incidents);
• Realizable – resulting in an important but intangible (unquantifiable, unmeasurable) improvement in some factor that supports the objectives of our organization; or
• Speculative – maybe the project will deliver this benefit and maybe it won’t but we think we should try.

Our classification must be honest. Any benefits that we believe are monetizable or quantifiable should be accompanied by current and target values. We should also identify who will confirm that those benefits are realizaed after the project and when they will do that. (Those people should be approvers of the business case.)

Writing a great business case is easy. It just takes a little discipline.

When I began my career as a maintenance strategy consultant and RCM facilitator in the 1990s, we used techniques such as Reliability Centred maintenance (RCM) and Failure Modes and Effects Analysis (FMEA) to analyze assets such as oil platforms, pipelines and petrochemical plants to determine appropriate maintenance strategies for each piece of equipment. There were essentially three strategies to choose from.

1. Reactive – fix it when it breaks, and hold a spare if downtime is a concern
2. Preventive – try to predict the safe or useful life of each piece of equipment based on analysis of past lives of similar equipment, then intervene at a pre-determined point in its lifecycle to refurbish or replace equipment thereby resetting the lifecycle clock
3. Predictive – try to identify a signal (a measurable condition) that indicted the probability of equipment failure was increasing (e.g., vibration, metal particles in lubricating oil, gases dissolved in transformer oil), then intervene when this signal reached a certain threshold to refurbish or replace the equipment thereby resetting the equipment’s condition

Predictive was the best strategy, particularly for equipment that was critical to safety, environmental protection or productivity. A predictive maintenance strategy allowed intervention before failure occurred (reducing unplanned downtime) while avoiding the replacement or refurbishment of equipment that was old but in good condition (reducing planned downtime and maintenance effort).

But there were problems. Condition monitoring equipment had to be retrofitted (e.g., gluing vibration monitoring points onto rotating equipment). Readings were gathered manually by technicians who lugged measuring equipment around the plant. That measuring equipment had to be regularly calibrated. Data was only gathered periodically – maybe monthly. The resulting data was stored in proprietary, stand-alone databases where it could only be accessed and interpreted by highly trained specialists. Those specialists were human and their predictions were not always reliable.

That was 20 years ago. Now technology is becoming mainstream that solves these problems.

• Low cost sensors that measure condition almost anywhere – even jet engines in flight
• Communication networks that communicate data from the field (or the air) in near real time
• Systems that can ingest and analyze very large volumes of data in a very small amount of time
• Artificial Intelligence that can find correlations between measurable conditions and incipient failure that even expert technicians cannot see

These technologies – Big Data, IIoT and AI for the jargonista – will revolutionize the field of Asset Performance Management.

General Electric’s recent acquisition of three vendors in precisely these areas – Bit Stew, Meridium and Wise.io – plus its huge installed base of asset-intensive customers means that GE is poised to lead this revolution.

Now, I wonder if GE can build a robot to go out and replace the failing equipment too!.

Over the past 25 years I have been fortunate to have participated in dozens of superbly managed projects (as well as one or two less well managed projects!). I have worked with good project managers and great project managers, and there is a set of attributes that all great project managers share. I want to share them with you.

Rock-solid Fundamentals

To be a great project manager you need a strong grip on the fundamentals. These fundamentals are a set of processes that manage a project’s scope, schedule, team, budget, quality, issues, risks and communications. A great project manager begins by establishing these processes – being sensitive to the project’s size and complexity – and maintains the discipline necessary to stick to them.

Leadership

A great project manager is a great leader. They provide a clear vision of the goal and a clear path to that goal. They sense when the team needs to heat up or cool down, and make the necessary adjustments. They act consistently and fairly at all times. They pattern the behaviours they expect in others, and hold them accountable. Finally, if they mess up they fess up, and then they move on.

Responsiveness

Great project managers always answer the mail. They provide a fast response to any question (my rule is one business day). “I’ll get back to you by Friday.” is an acceptable response. “I can’t answer, please ask Karen.” is also acceptable. The key is to never leave someone wondering if you got their message or if you care about their problem. Problems don’t age well.

Anticipation and Judgement

A great project manager continuously and realistically assesses current project conditions across a broad range: technical issues, customer satisfaction, team performance and so on. They know who to consult, and when. They use both their head and their gut to see problems before they occur (if you have been doing the job for 20 years you should feel when something is wrong). They take timely and measured action – at the very least go find out if their gut-feel is right. They don’t over react. They make decisions in a timely manner: sometimes rapidly, sometimes gradually.

Organizational Awareness and Influence

Great project managers can shape opinion. They are always well prepared and articulate. They build relationships before there is an issue, not once there is an issue. They pick their battles, asking two questions: do they care enough to fight for a particular outcome, and can they win if they do fight? A great manager understands the personality type of all key stakeholders, knows who has power, and understands what their objectives are.

Communication

To be a great project manager you must be a great communicator. Great managers understand that it is the responsibility of the communicator to confirm that the communicatee is receiving the message and understanding it. They don’t just issue communications, they consult and confirm to ensure that their message has achieved the intended result. They also know when to include someone in the conversation, and when not to.

Facilitation and Decision-making

Finally, the great project managers help the team to clarify issues or ideas. If a technical person and a business person are not understanding each other, then the project manager translates for them. They help people make decisions by providing a process for decision-making that:

• Asks clarifying questions like “what problem are we trying to solve”;
• Assesses all the options (and remember that doing nothing is always an option);
• Identifies the option that best meets the objectives;
• Helps everyone buy into the decision (e.g., make sure everyone is heard); and
• Records the decision so that we don’t forget and make the decision again later.

They also know when to step in and just make the call. No analysis paralysis.

These are the hallmarks of great project managers. They are not what great managers do, they are ways in which they get things done. Seven habits that separate the good from the great.