




Separating sales from reality


A couple of tips for doing this effectively include:



Make sure to write the weekly status report!






Building credibility one step at a time


  • Requirements
  • Action Items
  • Issues log
  • Validation Sign Off



Action items


Issue log


  1. who reported the issue?
  2. what is the issue?
  3. when did this issue happen?
  4. where in the system is the issue?
  5. how can the project team replicate it?

Validation Sign Off



Project plans are your source of truth

It’s been a while since I last wrote about project plans, calling them living, breathing documents. As part of the recent series digging into the critical components of scope and estimates, project plans are the next logical discussion point. Project plans are the manifestation of the scope and estimates. It comes in the form of gantt charts, excel work breakdown structures, calendars, etc.

The project plan, in whatever form, is a combination of tasks (scope), timelines (schedule ), resources and cost (sometimes). They can be high-level or very detailed. They should show dependencies among tasks. However, I would caution you to make them too detailed, as they aren’t set in stone, and making them complicated means it can be painful to update. Give yourself and your project team enough information to see what needs to happen, when it will happen, and discussion points for scope changes, issues, etc.

Most project managers have their preferred tool. My preference is the simplest tool for the project team. In my cases, this is usually a work-breakdown chart in excel. Excel is something that most business professionals know how to use. You also have flexibility in how much detail you provide and it’s fairly easy to update.

Most important is for the project manager to be regularly reviewing and updating the project plan. Always accurately represent where you are in the project. This is something that you should be sending out to key stakeholders on a weekly, or semi-weekly basis. It really does become the point of reference for discussions. Stakeholders may not read it, but you can use it to guide discussions, and point to it as the single source of truth. This is key.

Estimates are just educated guestimates

In my last post, I introduced scope. I defined it, explained how it can go wrong, and discussed the key role of the project manager to manage it. This week, I’m going to dive into some thoughts on scope definition and estimates. With everything I said last week about scope needing constant supervision and management, how is it possible to effectively define project scope?

scope-creep-monsterThere is a reason that we refer to the assignment of hours to tasks in projects as estimates. They are rough calculation, or less eloquently referred to as guesses. There are too many unknowns in software or data integration projects to be 100% correct, 100% of the time. However, there are definitely tips and tricks that we can use to get us a point where we are right more often than wrong (although that is a relative number when you consider that scope creep or changes are to be expected).

So, where do we start? We start with gathering as much information you we can about the work to be done. In the sales process, there are usually some very high level swag timelines thrown out, with caveats (AKA assumptions) that point to the need to fine-tune the timeline as the sales process continues. The next steps is to think about those tasks as they relate to functions and tasks your organization has done before. While it may not be the exact scenario, you can usually assign a relatively good initial estimate.

A common error in estimating is trying to estimate a task that is too broadly defined. Make sure you create tangible component tasks.

If a requirement is totally new, or you are using new resources, or there are quite a bit of unknowns, you need to take that all into consideration. You should look at similar work and then apply some multiple of time to account for your unknowns. This is where documenting your assumptions becomes critical. Like the scope definition, estimates and their corresponding plans (work breakdown structures, project plans, etc) are all living, breathing documents. They need to be reviewed, updated and acknowledged regularly.

A separate issue in all of this is the alignment of scope to project cost/budget. This are two very different things. When you are scoping a project, it is in your best interest to scope it fully. Do not consider the customer or organization budget in that matter. It is a strategic decision by your organization (sales, executive, etc) to decide what is charged to the customer for what scope. Negotiation of fees and scope will happen. Your goal should still be to stay as close to budget and timelines as you can, but understand that there can be other circumstances in play.

The biggest take-away to all of this is, you have to start somewhere! Monitor your estimates, update and communicate regularly and then learn from it. Apply the learnings to the next estimates you need to do.

Trust that your scope will change

The Project Management Book of Knowledge defines scope as the project boundaries. I prefer this definition on TechTarget:


From a practical project management perspective, what does this really mean? Who gets to define this? How do you manage? Let’s delve into the details of a scope.

A very simple evolution of a project is sales > implementation > support. Scope is relevant in each of these phases, however it may not mean the same thing to the stakeholders key to each phase. A company agrees to invest money in a project to solve a business problem. A salesperson has convinced the company that they have the solution. Here’s the first step of the process where scope can diverge. Can the corporate decision maker speak for all the business stakeholders? Do they really understand the details of the business problem that needs to be solved for each type of user? And how about the sales person? Do they really understand the software? Do they understand the business problems it can solve? Are more technical sales engineers involved in the sales process?

That simple example involving just the corporate decision maker and the sales person is indicative of how scope can rapidly become a problem in a project.

Scope must be managed throughout the entire project. 

Over the course of my career, I have had different levels of involvement in the sales process. Some I was involved from the first demo/sales call with the customer, others I help with preparing estimates and potential timelines, others I inherit after the contract is signed and others I inherit long after the implementation. It doesn’t matter at what point I become involved in a project, my first action is to receive a copy of all project artifacts. And yes, I do read that contract. I want and need to know what was committed.

Unfortunately, I’m not done there. I take the details I can find in the contract and communicate those out as often as I can. If this is a large project with multiple business teams, I will review the scope with each team. This is the opportunity for your customer, and more specifically the business users, to vocalize their agreement (or not). Either is fine, but it is imperative to align expectations. If there is disagreement, it is the responsibility of the project manager to sound the alarm to the corporate decision makers, and the services and sales organizations. Misaligned scope results in 1) unhappy customers, 2) stalemate of customer and company or 3) mutual agreement to realign scope. Note: The scope doesn’t necessarily have to be immediately changed. It is sufficient for the new work to be phased in after the initial scope implementation.

This is definitely a rinse and repeat process. Business are changing on a daily business, and implementing data and software projects means your environment is constantly changing. Time doesn’t stand still during implementation projects. This means new inquiries and requests come up constantly. Each time, you need to figure out how it fits into the work you are already doing. Some requests can be easily accommodated, but others need a deliberate approach to determine how it impacts existing goals, timelines, budgets, and overall commitments.

Do not fear the scope. The scope is your friend. It provides guiding principles for the work you are doing, and the goals you are accomplishing.

It really isn’t all about the numbers

Sitting at the intersection of business and technology means that I can interact with both groups. As a project manager who specializes in data projects, this often means diving into the analysis of the data, for validation, or understanding requirements, or more importantly to help craft a story, preferably around project success. Companies are becoming more data savvy, hiring Chief Data Officers and data scientists, and focusing on numbers to drive business decisions. I am very supportive of this, but we need to be careful to remember that it’s not just about the numbers.


More important is how we use these numbers to tell our stories. If your customer presents you with a problem, and a set of data that supports their conclusions, you need to look at it end to end to determine how to approach your story. Here’s a few thoughts on how you might approach it.

  • What were the assumptions made? In lieu of other information, we start with a core set of assumptions. It’s good to recognize and document these assumptions. It’s also good to challenge the assumptions if you have information not previously considered.
  • Evaluate your inputs end to end. Start at the beginning of the process and evaluate each step to understand the decisions made, and how those decisions impacted the outcomes.
  • Evaluate the outputs. There are so many opportunities to introduce uncertainty and inaccuracies into human process (data or otherwise). Was the data entry manual? Is there evidence of irregularities? Does the output make sense in relation to the logic of it’s corresponding process? Systematic logic is still at the whims of the people who write it.
  • Challenge the conclusion. While it’s important not to be defensive here, you do need to consider the “foregone conclusion”  and make sure it withstands probing and prodding. This is where perspective and point of view comes in. Make a conscious determination of the story you are telling based not the facts.
  • Communicate the deficiencies. If you go from one extreme to another extreme, swapping the entire frame of reference, it raises questions and credibility issues. As you are diving in and crafting your story, make sure to highlight deficiencies and inefficiencies of all components. Try to be balanced in your analysis, taking into account the work your customer took before it came to you.

There are lots of methodologies being used for diving in to real root causes (i.e. 5 whys, fishbone, etc). In data projects, it’s about being able to understand what the data is telling you and being able to convey that in a coherent and concise manner. Please don’t give me a bunch of facts, without an explanation of how you got there. This is the story. Understanding that data needs explanations, in the form of stories,  is why I do so well in managing my data projects.

Why is it important to put process first?


Let’s explore why that’s important.



When change doesn’t go your way





