Woody asks some important questions that have straight foreword answers in the software for money domain. These answers come for the business side of a software development organization. It's the business of software that needs estimates. Given a choice no developer really wants to estimate her work. I never did, I just wanted to code. But once there is an understanding that my paycheck didn't come from the Bank of America, even thought that's what it said at the top (above TRW), then I slowly learned our customers paid of some value (in that first job a missile defense radar system) they needed to know how much it was going to cost to produce the needed capabilities.
So here's some good questions that have answers from the point of view of those paying for the cost to produce the software for the customer.
So some further questions?
Knowing what it costs to produce a specific value is a critical success factor in any business. Writing software for money is no different.Related articles Estimates and all that... Resources for Moving Beyond the "Estimating Fallacy" Danger Will Robinson Managing Risk and Uncertainty in Agile Why Estimating Is Mandatory It's an Estimating Problem not A Problem with Estimating The Value of Making An Estimate
There are many hiring traps and shortcuts, especially for technical people. Partially that’s because too few HR people know about technical people. But, partially that’s because too many technical people think, “I have a job, I must know what it takes to hire well.”
In my most recent management myth, Management Myth 27: We Can Take Hiring Shortcuts, you can read about four hiring shortcuts I have encountered: hiring barrel-of-the-bottom candidates, supposed ‘rock stars’ or ‘ninjas,’ not paying people what they’re worth, or people who don’t fit with the team.
The dialogue in this myth is paraphrased from a real conversation I had with one of my VP’s many years ago. He wanted to help me by hiring Kelly Temps to help with testing. He was not a stupid man. He did not understand the value testers brought to the organization. I realized I had not done my job yet as a middle manager. Even though I’d only been in the organization for three months, I had not yet “sold” him on testing.
Hiring shortcuts can kill your organizational capacity. If that is your hiring strategy for now, decide what you will do later.
Read Hiring Geeks That Fit for more help.
The discussion (of sorts) on Twitter around "no estimates" - what ever that actually means, since there is no definitive description other than exploring - brings me back to my core program management, project management, writing software for money, designing algorithms for identifying moving targets in radar systems, and other software engineering experiences.
Let's start with a fundamental pricniple of all product or service development, either internal or external. While leading a couple hands full of project managers at a large Department of Energy environmental cleanup site, where software development was a critical success factor - and by the way we introduced eXtreme Programming into an ANSI validated Earned Value Management System - our external consulting firm gave us some good advice. We were bidding our technology and services at another DOE site, with similar cleanup problems. We were working on strategies, balanced scorecards, systems architectures, and the like.
That's all nice boys and girls, but here's some fundamental advice - our customer has money and we want it. What's it gonna cost and when will you be done providing the capabilities to close this site?
That's it, that's the winning strategy. The customer has a need, we want to providea solution to it. How much will it cost and when will we have it. If we can answer those three questions - cost, schedule, delivered capabilities, with attached unassailable beneficial outcomes - we will win. This is a business strategy. All the Balanced Scorecard presentations, examples of past performance, deep references of success, are all for naught if the customer can't afford our solution. It comes down to this - and this is where I learned this from the Managing Partner of the Big 6 (at that time) consulting firm.
You can't know the value of something until you know its cost
That's a fundamental principle of all business transactions. Value is always exchanged for cost. We do this when we buy a Venti Nonfat Latte at Star Bucks. We do this when we pay the lawn care company to mow and trim weekly. We do this when we buy anything, including software or the services that produce the software.
This is an immutable principle of commerce
So when we hear, there are alternative ways of writing software for money that don't involves estimating the cost of doing that work, think again. How did you get around the immutable principle of commerce? Now notice I used the word estimate in the same post as know. Yes, estimating allows us to know something to some level of confidence.
I'll estimate that my 1 hour drive to work everyday, will be extended to 1 hour 20 minutes when the snow storm arrives tomorrow night.
I know I'd better have margin in my drive schedule, if I want to attend the 8:30 stand up.
I estimate that it will take 3 days to install and verify the database for the system, given the historical data from the last 3 times we did this.
This knowledge can then be used to plan the access to the server room, arrange for all the verification and validation data we'll need to certify the contents are ready for use by the customer.
We estimate to a degree of confidence, things (time, cost, performance) we'll need to know about to do our job.
So How Can We Learn To Estimate?
Here's where we start. We start with what has taken place in the past. We've never done this before you say. I'd suggest, working literally in the rocket science world, there is very little in the commercial software world that hasn't been done by someone, somewhere in the past. You may not know these people, but it's been done. And more importantly it's the people issues that muck up the project most of the time, not the technical, unless of course it actually is rocket science, or stealth fighter science, or bioscience.
So with the second best basis of estimate approach - What is this like? We've done similar things in the past, how is this problem like those solutions? Next comes the 10 questions approach. The Planning Game. Then a parametric approach. Function Points, COCOMO, SEER, Price-S, SLIM, CoStar, and a long list of other basis of estimate tools, some free can guide you. So when you hear software can't be estimated, change the phrase to I don't know how to estimate software projects, but I can sure look into learning how.
Finally the least desirable way to estimate is to ask the expert. This only works if the expert has been calibrated with a reference class, has her optimism bias in check, knows all about anchoring and adjustment, and has a track record for producing credible estimates. If not, you're going to be disappointed in the result.
But our management uses our estimates against us. Our management doesn't understand the notion of probability and statistics. Our management behaves like Dilbert's boss. This has nothing to do with the need to estimate the cost, schedule, and technical performance of the product and service needed by your customer. It has everyone to do with managing up. And if that's not possible, producing a credible estimate with those risks baked in to protect yourself. And if that's not possible start looking for a better manager or even a better job because your company is going to be in the ditch before long.
So when we hear that estimating is the smell of dysfunction - without ever listing one single dyfunction - remember there are lots of dysfunctions in business. This is normal, because humans are involved. But that dysfunction is not caused by the need to estimate. The need to estimate is a core business process. Doing bad estimates, doing estimates for the wrong reasons, doing estimates wrong - that's a dysfunction that is universal.
In the end you need to either nut up or shut up as Woody says. Yes, that Woody. Learn to estimate for all the right reasons, then when there is an opportunity to have an enlightened manager at your current firm or a new firm, you'll be prepared to contribute value to the business process in ways that benefit the top line.
Since that top line, minus the costs to produce the goods or services is the bottom line (in it's simplest form) is what writing software for money is all about. Knowing the middle line - costs of goods sold (COGS) is critical to actually staying in business.Let's Stop Guessing and Learn How to Estimate Facts and Fallacies of Estimating Software Cost and Schedule
There was a question posed on LinkedIn
How do you get Project Manager understand the importance of Earned Value Management?
It's been shown over and again when we make EV a compliance process and hold managers accountable for compliance it is a necessary condition for success, but far from sufficient.
Until EVM starts providing actionable information to the program management staff in the form of "leading indicators" it will always be one of those compliance processes. This information must reveal where in the program, technical and programmatic changes can be made, the testable outcomes of those changes on program performance, and the impacts on cost and schedule forecasts and the EAC against the BAC. Starting at the program level, but going down to the Control Account and Work Package.
In other words...
Nice data there in your Formats 1-5 and really nice IMS, what should I do next?
EV numbers themselves are lagging indicators, non-statistically adjusted, non risk adjusted, not connected to the effectiveness and performance measures of the project - unless enlightened users do so - and not connected to the needed capabilities of the customer as delivered by the program. There is no DID for the IMP, so Systems Engineering rarely flows down MOEs and MOPs - except where they do, because of the knowledge of the power of this approach.
Next is a real problem. 748-C has a loop hole big enough to fly a 787 through. In section 3.8 "Earned value is a direct measurement of the quantity of work accomplished. The quality and technical content of work performed is controlled by other processes." Measuring quantity is a construction centric view of producing value. Not a value centric view. Our defense, space, biopharma, software intensive programs that apply EVM are not pouring concrete or welding pipe. (I used to work in that domain as a SW developers on piping design systems). If we see EV as measuring quantity we ignore all the concerns Paul Solomon has brought forward, starting with the missing Technical Performance Measures for the product.
Sure we have exit criteria for the Work Packages. But these need to trace vertically through the IMP to the Capability to accomplish the mission or provide a solution to the business need. In other do something with the resulting product or service. It has to be the right thing of course. But EV - as stated in 748 - only measures to quantity of parts needed to delivery a capability, not the ability of the system to fulfill the needed capabilities. This by the way is essentially a Systems Engineering issue. With the missing IMP, most of the motivation for connecting the dots between EV and mission success is simply not there. It's back to the immutable principle
We don't know what done looks like in units of measure meaningful to the decision makers
"Earning value" means assessing the efficacy of the BCWS. This means assessing the Technical Performance Measures of the work be delivered. Many implementations assign TPMs and QBD's this work. But this is not called out in 748-C nor any formal EV guidance. It is called out in the DAG and the old SEMP DID. No SEMP DID is in place.
So as EV practitioners we need to make the business case of EVM, not just the compliance case. When we add "leading indicators" that are statistically sound (Eric Druker has written about this as have others, including me), forecasting of EAC based on ARIMA processes rather than our linear, non-statistical, non risk adjusted CPI/SPI measures. As well those measure "roll up" the variances of all the past time series data, just like Darrell Huff tells us to do in "How To Lie With Statistics".
All the data is available in the EV engine and in the CR at PARCA for DOD jobs. What's next is to start using EVM in the same way supply chain managers, quality control managers, systems engineers, and every design and manufacturing engineer does - compare statistically adjusted performance against the probabilistic plan to see leading indicators emerge of where we are going to go into the ditch in the future, show the PM, that corrective action "before the fact" rather than after.
This will be a topic discussed at EVM World and ISCEA conferences coming soon.
Project success is elusive in all business and technical domains, including software development, construction, new drug development, any project involving multiple participants, irregular funding, and emerging requirements and risks that haven't yet been identified and handled.
To increase the probability of project success we must start with principles and apply practices implemented by processes known to produce benefical outcomes. Without these principles the practices and processes have no home.
These principles provide the framework for practice and process. Let's establish them first:
Identify the Technical and Operational Capabilities
The capabilities needed for success of the project, mission, or business are defined by the customer. Through a strategy development process or some other process that states why these are needed in units of measure meanigful to the decision maker. These measures are stated as effectiveness and performance goals.
Construct the Sequence of Capabilities
The capabilities must be delivered in an order that maximizes business value, minimizes risk, and maximizes opportunities along the way to make improvements for the customer.
With the sequence of work in place, we can now look for risks to our success and opportunities for improvement. Risk is created by uncertainty. Uncertainty comes in two flavors:
With sequenced capabilities, risk handling plans, and opportunity plans we are now able determine the cost and schedule of the work needed to deliver the capabilities. This work starts with packages of work holding the budget for the work and describing the period of performance. This result shows us the cost needed to produce each capability. This cost can be compared to the beneficial outcomes from the capability to confirm the business case or mission strategy if viable from a business point of view.
For each chunk of work in the plan to implement the needed capabilities we need some method to measure progress to our plan. These measures must be based on tangible evidence of physical percent complete. This can be done through three basic approaches.
Each of these assessments of progress to plan is based on a pre-defined unit of measure. This avoids the opinion of progress we often see on projects stuck at 80% to 90% complete. It also prevents measuring progress with the passage of time and consumption of money. Even the notion of working software has to have a tangible measure of working. Passing a test is fine. Is it the right test to confirm that a requirements is fulfilled to deliver a capability?
Each capability of the insurance provider network ERP system above is developed in a planned sequence to provide value in support of a business strategy. This order includes minimizing risk and maximizing opportunities. Each point where capabilities join the business can put these to work in generating value.
We need to know what DONE looks like, how we’re going to arrive at DONE on-time, on-budget, with the planned capabilities, what resources, funding, and work sequences we need, what risk handling and opportunity management can be performed, and how we’re going to measure tangible physical percent complete along the way.
These Principles enable 5 Practices and 5 Process to be implemented to increase the probability of project success. The details of all these can be found in Performance-Based Project Management(sm).Related articles The "Real" Root Cause of IT Project Failure Performance Based Management
I have a new column up on project management.com. It’s called Debugging Your Geographically Distributed Agile Team. (You have to register to read it. Registration is free.)
You can do agile with geographically distributed teams. You might not be able to do Scrum. You have other choices of approaches.
Helping a team form is tough. This article, which is true, shows how tough it can be.
Do you have similar experiences? Different experiences? Let me know. I’d love to hear from you.
It's not you money, behave apprioriately.
When asked to develop software in exchange for money - this is leaglly called work for hire - we have an obligation to have some notion of the final cost. If not, we're likley working a staff augmentation and not doing work for hire. So let's assume we are on a WFH engagement. Knowing something about the final cost starts with estimating that cost. This estimate says its name - it's an estimate. It's not a firm price. It's not even a firm anything. It's an estimate.
This estimate can come in several forms
The answer to both of these approaches comes from making estimates. Estimates of cost and schedule. Estimates of capacity for work. The process for making these estimates is called Basis of Estimate and usually starts with an anchoring nbsp;process.
By anchoring it means making the estimate from something that can be used as a reference. It's been done before, there is a model of what could be done. Some reference class. This anchoring process is then followed by an adjustment process. Adjustments can come in a short time, or over a longer time. But the anchoring and adjustment paradigm is well developed.
One research study has shown
One way to make judgments under uncertainty is to anchor on information that comes to mind and adjust until a plausible estimate is reached. This anchoring-and-adjustment heuristic is assumed to underlie many intuitive judgments, and insufficient adjustment is commonly invoked to explain judgmental biases. However, despite extensive research on anchoring effects, evidence for adjustment-based anchoring biases has only recently been provided, and the causes of insufficient adjustment remain unclear.
Anchoring and adjustment is well studied in behaviour finance - why people make financiual decsisions that they do. Anchoring and adjustment is also well studied in estimating starting with Oil & Gas estimates of reserves to estimating public works projects. A complete litertaure search can be found from Google of course.
But estimates needed for making business and techncial decisions must take this research into consideration is they are to be successful. For cost and schedule estimates the best place to start is past performance. Here's an orginal drawing of Flybjerg's Reference Class Forecasting process flow. Google will find you all his work as well. Many about infrastructure and some about IT.
When it is mentioned we haven't done this before so we have no reference classes, we have to pause and think. Is this a trueGreen Field project. Technology that has actually never beed done before is rare in the IT world. If this project is truly without precedent, it's likely an R&D project and need to be planned much differently.
So assuming this is not an R&D project, what can we do about creating estimates when we have little past performance? There are many tools available, some free, to start the estimating process. To produce an anchor estimate, we can start to refine before the project starts, or even after the project starts.
There are three types of activities that paerticipate in the estimating process
So when we hear estimating is the smell of dysfunction and no dysfunctions are listed let alone any credible and in use estimating processes, it's time to question the wisdom is assuming estimates are the problems with software projects.
So let's invert the conversation for a moment.
In the end it's the business that needs the estimates of the developers have decided they are not useful. It's not the developers money - if it is no one cares how they spend it. The business has a obligation to the shareholders, investors, the funding agency, to have some understanding of what the cost for the products or services will be when they are done.Related articles How To and How Not To Make Credible Estimates of Cost and Schedule Facts and Fallacies of Estimating Software Cost and Schedule It's an Estimating Problem not A Problem with Estimating 8 Reasons Why Estimates Are Too Low The Value of Making An Estimate
From the Ask Tom mailbag -
Any advice as to how to align all members from multiple cross-functional departments into one purpose; create an efficient, streamlined process that assures that communication, documentation and actual product flow is executed efficiently? We are specifically a design firm, but our revenue comes from the products manufactured from our exclusive designs. So, we have mature internal systems in each department, but the transitions of work flow from one department to the other sometimes break down, so there are logjams, finger-pointing and sometimes, general chaos.
Much of the answer is in your question. Let me pick out your key words.
Let me add three more.
What you have described is the classic transition from Stratum III systems to Stratum IV system integration. It sounds like you have done an adequate job of creating multiple internal systems, that are efficient in each of your workflow disciplines. It is the integration of these systems that is giving you fits. Let me take a stab at listing some typical systems in this flow.
Each of your internal systems likely works well within itself, but now you are experiencing balance problems between your internal systems. It is not sufficient to have a great design system and a great production system. If you have a weak prototyping system, your designs will get stuck on paper and never make it to production. You may have a great marketing system that creates consumer demand, but if you have a weak finished goods inventory system, your products will never find their way to distribution. Your weak systems will be doing their best and your strong systems will be finger-pointing.
So, that’s the problem. What is the solution? This is a Stratum IV issue, where someone needs to have end-to-end accountability. Some companies attempt to solve this problem by creating a role called product manager. The product manager would be accountable for tracking each step, likely creating a Gant chart of product progress from one function to another. While this role gathers necessary data about the status of a single product in the chain, it still might only document that the product is stuck.
That is why this is a Stratum IV issue, one of balance and integration. The S-IV manager (likely a VP) would be accountable for examining each system for capacity and handoff. This is not looking internally at the mechanics of a single system, but the interaction of each reinforcing system to each balancing system. It is not a matter of having one or two high performing functions, but having all functions able to keep up with each other, optimized for capacity. No single system manager will have the authority, nor likely the capability, to do this work.
And somewhere in this integrated whole system, there will be a constraint. There will be some limitation in a single system which will drive the cadence of all the systems working together. The hat trick is identifying and placing that constraint strategically. Typically, this strategic constraint will be an expensive resource, too expensive to duplicate (which would double the capacity of that system). The identification, selection and placement of the strategic constraint, and then subordination of all other systems to the strategic constraint is the work of the S-IV manager.
With this integrated system design, then the work of documentation, handoffs, communication and feedback loops begins. Most companies get this backward and have a communication seminar without balancing the systems for total throughput. You can imagine that this communication seminar makes everyone feel good, but nothing changes in throughput, the finger-pointing continues.
Shim Marom provides thought provoking posts. The one on Estimates and Not Estimates was a perfect straight line requesting a response.
So some other thoughts:
If No Estimates is about making decisions, then No Estimates better come up with the cost of outcomes of having made that decision or that statement is completely bogus. Time to start looking for business value from our work efforts in building software for money. That means know the cost of our efforts to some degree of confidence before and during the project. Knowing afterward is simple and worthless, that horse ran away and know we're saying how much it costs.Related articles It's an Estimating Problem not A Problem with Estimating How To Estimate, If You Really Want To Moving from "Why" to "What" Actions are Needed? Why Hasn't #NoEstimates Produced Actionable Outcomes Yet?
Are you looking for job? Will you be in London on March 21, 2014? If so, you should join me for my Manage Your Job Search workshop.
You’ll each work on your own unique job search specifics. And, you’ll help each other get better. Here’s the outline:
Interesting? Sign up on the Workshops page. I would love to have you join us.
Phillip’s team looked at each other, across the table, and for the first time saw something different. No more were they simply co-workers, but now interdependent members of a group whose success depended on those connections.
“No one succeeds by themselves,” I said. “At least for anything of significance. Sure you can think you are the Lone Ranger and prance around like you are someone important, but to achieve anything of real significance, you need a team. Each of you will, at some point, stumble, make a mistake, misjudge a situation. Each of you will, at some point, become discouraged, or become a Prima Dona, full of yourself.
“And when that happens, you will not recognize it in yourself, soon enough. You need each other to tell you those things, to make each of you better. Without each other, you will end up in ditch somewhere and no one will notice.”
The AMACOM Book Performance-Based Project Management has a blog post from the publisher.
Back when I was a Director of many things at one company, we had an urgent patch to go to a customer. My VP wanted it “yesterday.” Well, time only goes in one direction.
I gathered my continuing engineering team, explained the pickle we were in. “Everyone wants this patch right away. However the customer is truly pissed. I want to know that we have a fix that works. And, while you are working on it, I will need to know updates every morning and every afternoon. I will run interference for you, as well as I can.”
Everyone groaned. They knew what this meant. We had a small company. The corporate management was just down the hall from our offices. Even though I said I would run interference, nothing would prevent the VP of Engineering, the CEO, or the CTO from popping their heads in “to see what’s going on.” Everyone wanted to make the customer happy, right now.
At the time, I didn’t know about kanban boards. I knew about spreadsheets and email. I had four people working on this fix. I knew what they were all doing. So did they.
They managed themselves. Their offices were close to each other. Every day, about noon or so, they gathered in my office, so I would have the most up-to-date status. It wasn’t quite a standup, because some of the work was what we would now call spikes. (At first, we had no idea what was causing the problem.)
As we identified the problem, I explained to management on behalf of the team how they narrowed down the problem and identified it. Then I explained to management on behalf of the team how they were debugging the problem. Then I explained to management on behalf of the team how they were testing the fixes they proposed. Then I explained to management how they were packaging the fix they had decided on.
If we’d had a visual board, this might have been easier. I used email. It took close to a month. It was a very difficult fix.
Notice what I did:
Because our management, and I could share the interim results with the customer, the customer was not happy during this month, but they were pleased to know we were working on the fix. By the time they got the patch, they were very pleased. It worked.
I did not micromanage my people. I understood their state. There is a big difference. And that is the topic of this month’s management myth, Management Myth 26: It’s Fine to Micromanage.
If I had stood over their shoulders, and asked, “Is it done yet?” I suspect I would have had different results.
My team understood that I was doing my management job. I didn’t prevent all other senior management interference. But, I prevented most of it. In return, they were free to work together to accomplish their goal: a fix that didn’t upset the rest of the system and really fixed this customer’s problem.
It’s easy to fall into micromanagement. We, as technical people are terrific problem solvers. We excel at it. We want to help other people solve their problems. Micromanagement is inflicting help on other people. It’s not helpful. It’s irritating and prevents other people from doing their jobs.
Have you caught yourself micromanaging? If so, what made you stop?
Much of the discussion on building products and services is focused on eliciting requirements, developing solutions around these requirements. Ignoring for a moment the silliness of not knowing the cost or duration of this work effort, we still need to address the business side of spending other peoples money in exchange for delivery a known value.
Over the past months I've come to see the world through the eyes of Systems Engineering. I have a MS in Systems Management, but haven't applied it in 25 years.
My current assignment is on a large software intensive system that is a national asset. This is a code word for it has to work as planned or 100's of million of people, sovereigns, and other users will be disappointed at best and possibly be put in harms way at worst.
This systems view means: (Systems Thinking for the Enterprise: New and Energing Perspectives)
So it all comes down to this:
If you don't know what someting costs - in units of money, schedule, manpower, infrastructure, tools, process risk, delay - you're not going to be able to know what it is worth.
That's it, It's that simple. Anyone suggesting their processes or even a HashTag masquerading as a suggested approach to problems, that this solution will increase the Probability of Project Success (POPS) or their suggested solution is focused on providing value to the customer, must address how that suggestion will work in the presence of the reality of building products and services in exchange for someone else's money.
Earned Value measures the production of tangible outcomes from work efforts on a project using Physical Percent Complete. This P%C is calculated used Quantifiable Backup Data shows what technical or operation goals must be met on a planned date in order to claim some Percent Complete. Measures of this physical percent are NOT how much money you spent or how much time you took to do the work.
They are only measured in unit of tangible technical progress to plan. This tangible technical progress is defined BEFORE the work starts. This progress goal is derived from the time phased Measures of Effectiveness and Measures of Performance goals of the project.
These MOE, MOP, KPP, and TPMs are defined below and their measures - in units meaningful to the decision makers - established before work starts, put on baseline and used to compare progress to plan (time phased) to produce that Physical Percent Complete in the Earned Value (BCWP) formula in the first chart.
I saw this post on Twitter, The 3 Interview Questions You Should Ask to Instantly Gauge Fit. I got excited. Oh, maybe we do have questions that address cultural fit.
If you are a candidate and an interviewer asks you these questions in the guise of a conversation, you should be disappointed, too. What are they?
Let’s review what corporate culture is: how people treat each other, what’s rewarded, and what’s okay to discuss. Do these questions address any of that? I don’t see how. Do the questions address how a person can do the job at work? I don’t see how.
Why would anyone ask these questions? (picture a short woman pulling out her hair.)
If you are a candidate, and you get these questions, here’s how you might answer these questions:
1. For the most interesting question, turn it into a behavior-description answer. Take a small thing that was indicative of your collaboration or facilitation or leadership. Make it something you did not highlight on your resume. As an alternative, make it something you chose to learn. “On my most recent project, let me tell you a story about how I facilitated <this thing>.” Or, “I really wanted to learn basket weaving. I know basket weaving isn’t part of the job, but it’s the learning part I wanted to highlight. Let me tell you how I learned.”
If you don’t turn this into a behavior-description answer, you will flounder and not be able to answer.
2. For the most interesting question, do not talk about your piercings. Or the vacation in St. Barts. Or the fact that you are related to English royalty. None of those things are related to your ability to do the job. Again, you need to turn this into a behavior-description answer. (This is why this is such a terrible question. There is no work context here.)
Think about interesting situations at work. You know how politicians only answer how they want to answer? You can do the same thing. You don’t have to answer the misconception question. You can say something like this: “Oh, I was in a project meeting. This is before we had a kanban board. No one knew the status of anything. Everyone was confused. It was like we were playing “telephone.” Finally, I said, “Let’s all create stickies and put our tasks on the board and see where we are.” We were then able to create a picture of the project and move on from there.”
You have distracted the interviewer from the irrelevant question, and provided the interviewer with evidence that you are a smart person who can move a project along. You have provided a behavior-description answer to a mind-boggling question.
3. What has to happen to make a great day is a hypothetical question. What if you’ve been unemployed for a while and you just want a job, even if it’s a horrible job? The problem is you can’t say, “Going to work will be a great day.” You sound desperate. You can’t say, “Being able to see my kid’s concert is a great day,” or “Arriving at 7 am and leaving at 4pm is a great day.” You want to know what the cultural norms are here. You want to ask those questions. Maybe you want to work on an agile team, but your version of agile is different from what these people think agile is.
Depending on how much you want this job and where you are in the interviewing process, you have some options:
If you are an interviewer, don’t be fooled by these questions. These questions don’t tell you if the candidate can do the job or fits your culture. (Read Hiring Geeks That Fit or more on this blog.)
If you are a candidate, deflect these questions and use behavior-description answers and auditions.
The blog post is correct in one respect: the best interviews are good conversations. But, they are good conversations that help you determine if the person can do the work here, in this culture. That’s why you ask about cultural fit.
All these misconceptions about cultural fit. I have got to get myself together and do an online workshop series about how to develop and ask questions about cultural fit.
From the Ask Tom mailbag -
Can you talk about the difference between a dictatorial management approach and a collaborative management approach?
Execute like a dictator!
No kidding. Execution often requires precision sequences of skilled behavior. Execute like a dictator.
But to be effective at execution (like a dictator) requires two things.
So, there is a time for collaboration and a time for explicit direction. And effective explicit direction does not (cannot) occur without collaboration in planning.
In football, collaborative planning is called skull practice. Off the field, in a room, no pads and no football. The group assembles around a chalkboard (whiteboard) and there are fierce discussions about problems and solutions, roles and assignments. At the end, even if there is disagreement among the players, they still pull together. People will support a world they help to create.
Skull practice is followed by perfect practice on the field, hours of it.
But, during the game, work instructions are short, often shouted, There is no time in the moment of execution to discuss who is going to carry the ball. But, effective execution only works when it is preceded by collaborative planning and perfect practice.
I’ve outlined five potential costs of delay in the previous five posts:
The real problem is this: Why should you care? Maybe you have a “sweet spot” in the way you start your projects or release them. “It just takes that long here.” (That’s the sign of a system impediment.)
Let me show you two pictures. The first you’ve already seen, the back of the napkin, where you see the effect on your potential maximum revenue.
Now, let’s try to calculate that cost of delay.
The longer your delay, the more your cost of delay moves your curve to the right. The more sales you lose out of the Maximum potential sales.
The longer it takes for you to release, the more sales you lose from the maximum potential sales. You wait a month to release? You lose a month of max sales. You wait a year to release? You lose a year of max sales.
That’s right. Do those numbers start to look big and scary now?
You not only have aggravation and impediments in your current project from the delays from multitasking, technical debt, indecision, slowdowns from other teams, you lose the potential revenue from maximum potential sales, every week you don’t release.
Now, I am not saying you should release horrible product. Goodness knows, we have enough of horrible product that barely works or doesn’t work at all out in the field. I want to see great products! The idea behind this picture is so people understand that it is worth their while to consider change.
You can change to shorter projects and release something useful faster. (See Manage It! Your Guide to Modern, Pragmatic Project Management)
You can change to agile or incremental lifecycles so they can see progress and release something useful faster. (See What Lifecycle? Selecting the Right Model for Your Project and Manage It! Your Guide to Modern, Pragmatic Project Management for an in-depth discussion of lifecycles. You have more options than just waterfall and agile.)
You can adopt a more reasonable approach to the project portfolio, and make decisions more frequently. (Does anyone really think project portfolio decisions last a year? Come on.) (See Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects)
You can consider paying off some technical debt. I used the build system in my example. I could have used automated tests or the thousands of defects some of you have in your defect tracking systems. It’s whatever prevents you from knowing you could release on a “moment’s” notice. I would like that moment to be under an hour. I bet for many of you, less than a day would be a huge improvement.
You can optimize for the entire project or program, not their feature or team. Too often, I hear, “My part is done.” That does not matter. It matters what the entire team, project, or program finishes.
In my talks about project portfolio management, I am fond of saying, “It doesn’t matter how many projects you start, it matters how many you finish.”
With cost of delay, it matters when you finish them. Because until you finish them, no one pays you.
I have taken a high level approach to cost of delay in these posts. I wanted to simplify it so you and I could understand it, a zeroth approach, if you will. If you want more information, start here:
Cost of delay is why you cannot take an ROI or use date or budget estimates to manage the project portfolio. This is why you must use value. I look forward to your comments.
Here is an interesting question posed over this holiday weekend.
How does a CEO gauge effectiveness in the role of CEO? Not conducting a 360 review for other’s perception, but how does the CEO track and consider those elements of CEO effectiveness?
Jack Daly describes the three most important pieces of the CEO role.
In some ways, gauging effectiveness may be in the selection of what the CEO should NOT be doing. Your thoughts?
Along with my series about interviewing tips, I thought you might need a few tips for editing your resume. Here they are:
You’ve heard “the devil is in the details,” right? You want a hiring manager to see you as a unique individual, someone who cares enough to provide a great resume, and someone who has done terrific work.
When I checked some text in Grammarly, it did find the commonly misused “Principle Engineer” problem. Yes, I know some of you are called “Principle Engineers” instead of “Principal Engineers.” Some HR person does not know the difference and it has spread like wildfire through technical job titles and job descriptions.
Principles are rules, tenets, laws, things like that. People are not principles.
Principals are leaders. People can be principals. There is a nice post on the Oxford Dictionary site, Principle vs. Principal that explains it well.
Why do you want to do all the work of Step 2, with the details? Why do I insist on articulating your value like that?
Because you need to explain what you have done in your jobs, so that you can answer questions well in the interview. You leave the stories of your career for the interview. You summarize the details with numbers in the resume. Is this difficult? Oh, yes. Is it worth it? Oh, yes.
Your resume is a piece of writing, the same as any other writing. It represents you to people you don’t know. Do you want it to say, “I’m a schlub,” or do you want it to say, “I’m a terrific person. Here’s what I’ve done in the past. I’ve told you the details of my previous work. I’ve checked that I’ve represented that work properly. Here I am! Now, interview me.”
That’s what a great resume can do for you.