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.
- Are you willing to give an estimate/price for free?
- The cost of sales is factored into the wrap rate for any firm intending on staying in business for long. The revenue earned from work needs to cover the cost of sales, plus all the overhead, indirects, fringe, benefits, and finally have some profit left over. Knowing the cost structure of the business is mandatory.
- So you can absorb that cost of sales indirectly in the wrap rate our you may be able to charge the customer for specific efforts if they are beyond the normal cost estimating process.
- In the end though, knowing your market and being competitive in that market means you know something about what things cost. If you decided to get into the SAP integration business or the flight avionics software business (two areas I know about), you'd better not only be able to deliver value, but know how much that value costs.
- Without knowing the costs of delivery the value, you can't know if you're competitive or worse know if you can stay in business.
- Knowing the cost structure of your business is mandatory for any business.
- This is called cost of sales. It's a cost carried on the books as an expense.
- It's the cost of doing business.
- When I see free estimates for your local house painter, I'm reminded of our daughter (now an adult in the work force) coming home from her high school economics class - which we insisted she take - saying Dad today we learned there is no such thing as free.
- This question is answered simply by taking that high school economics class.. Some one has to pay. It's almost always the customer.
- This is called risk margin. Someone has to pay to cover the risk.
- If someone doesn't pay, you'll be out of business. Look at your contract. Don't know what to look for, better get someone on board who does. A business development person is a good start, if your the techie.
- Depends on how well the problem is stated. Risk goes up the less anyone knows what done looks like.
- This is a natural for agile development. A phased approach where a discovery phase is budgeted to find out the next level of detail for the cost of the project.
- The government does this through its 5000.02 acquisition strategy. IT shops do this. It's the standard thing to do.
- If the customer is unsure of what capabilities are needed, then the risk is higher, and the discovery phase more important.
- Of course you are. That's the basis of an estimate. Most Likely and a range around that ML value.
- No point estimate is credible without an estimate range.
- This can be arrived at through a wide variety of means. Too wide for this blog.
- But without the range and the shape of the curve for that range, no estimate can be credible.
- If the customer is asking for a guarantee, this is likley to get ugly real fast when the customer asks for that. Act appropriately. Have a lawyer write your contract. Start with a work for hire paradigm.
- Read your terms and conditions.
- Is this a time and materials contract?
- Is there a Statement of Work?
- Is there a list of deliverables? Do these deliverables have units of measure defining there acceptance?
- Act like a business person, the technical stuff comes next.
- You're in the business of writing software for money, behave appropriately.
- You're entering into a competitive environment. Or you've been assigned a job internally you may not know about. This is the time to start learning, rather than exploring. It's time to start being a good steward of your customers money.
- Reference class forecasting is one place to start.
- There are many tools that will help, here's a list.
- Estimating software costs is a very mature domain. Don't believe for a minute that it can't be done. Don't believe for a minute that you can't estimate nearly anything. If it is knowable and you have the means of knowing, you can make an estimate.
- This is a trick question. What does better way mean.
- A fundamental axiom of business is you can't know the value of something until you know its cost.
- Without this understanding your customer is likely not a good customer.
- Business, like poker, is not about winning, it's about not losing.
- Let the other guy lose money on the better way - if there is such a thing. Then learn from that to be better yourself.
- But the better way argument needs actual suggestions, not some open ended pie in the sky, chasing unicorns approach to running your business. Unless of course you're in the business of breeding and selling unicorns ;>)
So some further questions?
- Do you expect to make a living writing software for money as a provider or consultant? Then you'd better know something about your cost structure. How much do you need to make to eat? What rate can the market absorb for your services? What is your unfair competitive advantage? What is that worth in the market?
- What does the market place want to buy? What are they willing to pay? Who is providing that now and at what rate?
- Who is your competition? Are they expanding? For what reason? Cheaper, faster, better?
- How will you position yourself against them? Price, experience, faster?
Knowing what it costs to produce a specific value is a critical success factor in any business. Writing software for money is no different.
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.
Project management tools come in many shapes and flavours, and most of what I review is software designed to manage small and medium-sized projects. Primavera, on the other hand, is an enterprise-grade software solution aimed at companies with a mature approach to project management probably with a programme or portfolio management approach in hand too. But where do you start learning about a product that is huge and full of features that you might not understand, let alone want to use on your project?
Ten Six, a US-based consulting firm, has designed a video training course to help people get started quickly with Primavera. When you first install the software, you’ll probably have Primavera consultants work with you to get it set up correctly and they’ll do some on-site training. But by the time the next project manager joins those consultants will be long gone so you’ll need some other way of getting new starters up to speed. This video course could be it.
What you get: High quality video with sample data files and a 47-page exercise workbook. Also includes detailed instructions on how to download and install Primavera P6 if you don’t already have it.
Audience: Aimed at people who have never used Primavera P6 Professional.
Duration: You should be able to complete it in 2 days.
Length of access: 3 months. Ten Six will grant extensions if you email them to request one.
DVD provided? No.
PDUs? Yes, 7 category A PDUs offered.
The course starts with a 6 minute video about PMI’s process groups to set the whole thing in context. It’s actually a pretty useful summary of the project management lifecycle. The videos are fine. You don’t get a talking head trainer as they instead show you screen flows and slides to illustrate the points. This is a shame as I think it helps to ‘see’ a trainer from time to time to give you that idea of human interaction.
Each lesson includes a quiz and you can refer to the workbook for exercises to do on each topic.
There are 12 lessons plus 3 bonus lessons. You don’t have to take the lessons in order so you can skip around as you come across topics that you need to study right now. The lessons do build, though, so it would be helpful to start at the beginning and work forward instead of jumping straight to global project and report calendars (covered in Lesson 12).
Whether you do the lessons in order or not, the learning management system will record how much of the course you have completed so you can track how much you’ve done and how much you have still to do.
The Work Breakdown Structure video was useful, as it gave a general overview and then how that translates to the software. Some of the videos are too long in my opinion: the lesson on project reporting is 25 minutes long, which is a long time to sit and look at slides and a screen walkthrough. This could have been split somehow into two shorter videos combined with the exercises.
The bonus lessons cover P6 Visualizer (useful if you are using this module), percent complete types and progressing activities using steps. These lessons don’t have quizzes.
What surprised me was how old-fashioned the P6 system looks (although of course the training provider has nothing to do with this). The course is comprehensive and, while I’m not an experienced P6 user by any stretch, it looks to me as if it includes everything that you’d need to get started and build your skills in using this software.
It’s easy to navigate through the training and the workbook, and I think you definitely need the workbook exercises and associated data files to really get to grips with the software – you can’t learn to use it just from looking at the videos alone. Access to the videos is removed after 3 months unless you request an extension but it looks like you can download the workbook and data files and use these for as long as you want, which would be helpful if you wanted a refresher at any point.
I liked the quizzes and it helps confirm that you have picked up certain skills, especially vocabulary and navigation (which were most of the questions I got wrong). They would also be useful if you were training up a new member of staff as you could mandate certain pass marks before they move on to the next module.
Overall, I think project management training is moving more towards this sort of model: online, subscription-based delivery backed up by written materials and potentially remote support and tuition (although access to a tutor isn’t offered with this course). If you want a cost-effective way to get started with Primavera P6 with the flexibility of online learning without the hassle of going to a classroom then this course will meet those needs.
Full disclosure: Ten Six is a client of The Otobos Group, but I’ve reviewed this product independently and honestly and have not been compensated for it.
Copyright © A Girl's Guide to Project Management [Review: Primavera P6 Video Training], All Right Reserved. 2014.
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.
- Effectiveness is an operational measure of success that is closely related to the achievements of the mission or operational objectives evaluated in the operational environment, under a specific set of conditions. These measures are stated in units meaningful to the buyer, focus on the capabilities independent of any technical implementation, and a traceable to Mission Success.
- Performance measures characterize physical or functional attributes relating to the system operation, measured or estimated under specific conditions. These measures are attributes that assure the system has the ability to perform the mission and are an assessment of the system showing it can meet the design requirements at satisfy the Measures of Effectiveness.
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.
- This sequence should be detailed enough to determine dependencies but not so detailed to inhibit easy changes as we discover new requirements needed to fulfill the capabilities.
- The chart below shows an actual sequence of capabilities for a health insurance provider network ERP system. As each capability is delivered, it can be incrementally put to work in the business.
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:
- Reducible uncertainty– these risks can be reduced by spending money, changing our plans, or creating alternatives. Formally these uncertainties that create the risk are epistemic. This is risk related to the lack of knowledge about the situation. We can pay for more knowledge.
- Irreducible uncertainty – these risks cannot be reduced with more knowledge. They are dependent on chance. No increase in information can reduce the risk.
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.
- 0/100 – we’re done or we’re not done. Nothing in between.
- 50/50 – we’ll get 50% for starting and 50% when we’re done.
- Quantifiable backup data – a series of milestones each with some tangible evidence of completion, each representing some pre-defined percent complete.
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).
I didn’t know what to expect from Ann Pilkington’s book, Communicating Projects. It isn’t about just about producing a communication plan and while it is broadly aligned to the APM Body of Knowledge (6th Edition) it isn’t a guide to doing things according to any particular method or standard.
It turns out that the book offers practical help and guidance to the person on the team doing the communicating. She assumes that this isn’t always the project manager. On a large project team you may well have a project communicator (as she calls them) but the book could also be of use to people in a non-project role who find themselves being dragged in to prepare communication materials about a project they know nothing about – your corporate PR or Marketing team, for example.
Agree what ‘communications’ is
The first bit of advice Pilkington has is not to communicate. At least, not to communicate too soon. The first thing to do is to agree the role of the communication workstream. Who is going to do what? And what is it that you are going to communicate?
Communications have two objectives:
- To share what has been done (the output)
- To share what has been achieved (the outcome)
Outputs are things like producing newsletters or updating the intranet page for the project. Outcomes are things like ensuring that employees know what the project means for them. Your communication plans will need to include both these types of objectives, in a structured way. And that doesn’t mean simply issuing briefings. Pilkington writes:
Despite the fact that projects exist in a world of sophisticated media and advertising, there is a still a tendency for communication to be thought of as a simply linear process, that is, somebody is told something, they interpret it in the way that was intended by the sender and that is all that is needed. Where this ‘send out stuff’ approach still prevails on projects it is no wonder that stakeholders are cynical or disengaged and projects don’t realise their benefits.
And what it is not for
There are, Pilkington says, limits to what communications can achieve on projects. She says that the communication function is not there to:
- Replace good project governance
- Remove the responsibility for line managers to communicate with their teams directly
- Manage project documentation
- Massage the message and make bad decisions look good
- Stroke the ego of the project sponsor or manager
- Fix things that aren’t problems caused by or to be addressed by communication.
So, having got clarity on what the project communication function is supposed to be doing, how do you do it?
Strategy, content and execution
Chapter 2 covers communication strategies and includes a template. In fact, most chapters end with a template and sometimes a ‘vignette’ which explains an element of theory or gives an example. While the templates are good, I found the vignettes distracting and I can’t see why these haven’t been woven into the main body of the text.
Part of your strategy is defining your stakeholders and the book also includes a stakeholder analysis model which goes into plenty of detail.
Pilkington goes on to discuss the content of your communications plan in Chapter 4. She recommends that you don’t create a project ‘brand’ because it looks transient and “wacky”. I had never thought of this before but I have seen plenty of awful brands for projects and worked on branding my own projects – something I will now stop!
She does, however, recommend having a house style for communication that covers a consistent approach to jargon, fonts and so on to make your project look joined up, at least. Finally, when it comes to content she recommends having formal sign off for each item that is used or sent out. This makes a lot of sense, so as part of your communication plans and strategy you would have to define who gets to approve what.
Managing your message
The final two sections don’t fit the project management lifecycle particularly well but are good additions to the book. There is a useful section on crisis planning. Not all projects will need to take account of this, but yours might if it meets the criteria that Pilkington sets out. If you do think that crisis management might be needed (for example, if your project is going to make lots of people redundant and you think this might hit the news) then it is definitely worth being prepared before it happens.
The final section of the book is about evaluating your communications, which is something I don’t think project teams do routinely. The point of evaluating what you communicate is to check that it actually did what you wanted it to do. Pilkington recommends doing a communications audit to check the desired effect of your communications. She says:
Project communications should not be judged only by how much activity is undertaken, how nice the posters look or how busy the team seems to be. While there is some value in knowing how much activity has been carried out, this is no indicator or quality or outcomes.
Evaluation is worth doing because it helps you:
- Identify what is working
- Identify what isn’t working so you can stop or change it
- Identify lessons for a lessons learned meeting, based on evidence rather than anecdotes
- Prove that the communication function on the project is worth doing.
This last point seems particularly important to Pilkington as it’s also one of the reasons she wrote the book in the first place. She wants to elevate the communication function on a project to raise its profile, something which I can agree with.
Overall, this is a useful end-to-end guide and it is written with a wide enough audience in mind to make it valuable to anyone on the core team or in the extended business team who finds themselves responsible for communicating to others about a project.
Want to communicate better through your project status reports? Check out my online course and ebook, Better Project Status Reports, which is specifically designed to help you get your message across more effectively.
Copyright © A Girl's Guide to Project Management [Book Review: Communicating Projects], All Right Reserved. 2014.
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
- This customer has a budget and would like to know what can be produced for that budget. This is common in governance based domains. The owner Hubble Space Telescope had a budget to fix HST robotically. He got that budget from the NASA administrator. He released a BAA (Broad Area Announcement) for solicitations of what could be done for his budget. Some for a CIO of a health insurance company. She got a rough budget for upgrading the provider network ERP system and asked vendors to tell her what could be provided for that budget.
- The customer has a set of needed capabilities and needs to know the approximate cost of providing those capabilities and needs to know the cost to provide them on a needed date.
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 Forecastingprocess 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
- Stable activities are understood and predictable. Estimating these is straightforward.
- Dependent Activities where the time or effort is dependent on project attributes or characteristics not yet known but they are knowable.
- Uncertain Activities where little data is available to support the estimate with any confidence.
- Analogous Estimating using the experience from previous projects and extrapolating that onto the current project.
- Parametric Model Estimating is an accurate and easy estimating technique developed for estimating the time or resources needed to perform a project activity.
- Expert Judgment when there is an expert on the project.
- Published Data Estimating for those activities for which there is published data. The activity is compared to the activities for which data exists and the actual cost or durations of the closest comparable activity is selected from the data and used as the estimate.
- Reserve Analysis is fundamental for all estimating and considers the level of uncertainty and risk in the project and establishes a reserve pool of time, resources, or possibly performance that can be drawn upon to offset the unestimated issues that arise.
- Bottom Up estimates improves the accuracy of the overall project estimate requiring the project team to decompose the work into very small work packages.
- Total project budget is many time set even before the scope and schedule are defined. (construction projects funded by bank loans.) A high-level allocation of the budget is created between the likely project deliverables. Each major activity is estimated and if this estimate is greater than the allocated cost, the timing of resources or scope and deliverables are varied until the project is able to meet the budget goals. This is usually an iterative 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.
- Drip funding is suggested alternative to estimating. But drip funding just pushes the project estimate back to the project owner, who in turn releases budget. But the capacity for work the productivity of that work capacity still needs to be estimated to determine if there is sufficient budget to complete the needed capabilities on the needed date.
- Fixed Price funding move the estimating process to the providers of the product. They now need to estimate their capacity for work, risks, margin, and productivity.
- Decomposing work into same sized chunks - assuming this is possible - may be useful in some domain. But needs to be tested outside of the anecdotes of those using it.
- In the end the Return on Investment calculation [ROI=(Value - Cost / Cost)] used by all viable businesses needs to know both cost and value. These are both probabilistic, and the underlying statistical processes driving both these needs to be understood.
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.
Shim Marom provides thought provoking posts. This one was a perfect straight line requsting a respons
- Are cost estimates required in order to manage software projects? - without some forecast of how much the project is going to cost, it's going to be hard for those providing the funds to have any confidence that the project will stay on a budget needed for their target Return on Investment. ROI = (Value - Cost)/Cost. If those funding the project are in the business of making a profit (or operating wihtin the budget they've been assigned), knowing the estimated cost is important to their success.
- Are cost estimates an effective tool for controlling costs? - controlling costs is a management issue in nearly every domain. But without an estimate of costs we have not target cost for the project management processes. Without a target, we have an open loop control system. No target, no feedback, no corrective actions. With a target we have a closed loop control system, where feedback against the target is used to take corrective actions in support of #1.
- Do estimates stifle creativity and kill innovation?
- Do people need estimates? And if so, why?
- Is the very act of estimation results in the creation of uncertainty?
- Is estimation a practice still hanging over from the Waterfall era?
- Is No Estimation better than Bad Estimation?
- Is Estimation really just a form of Guessing?
- Are estimates necessary for Governance? Is it reasonable to require estimates for the purpose of pacifying governance needs?
- Is there any point in providing estimates when it is known that many projects fail due to lack of credible estimates? And aren't estimates a tool used to apportion blame afterwards anyway?
- Is costing a necessary tool for determining business value?
- Does the scope drive the budget or does the budget drive the cost?
- If estimates are required in order to support decisions, can decisions be made without estimates?
Recently one of the students taking my Better Project Status Reports course got in touch with some questions about risk and issue reporting. I thought it would be worth sharing my responses with everyone.
To give you some background, we were talking about a large project which would run over several years with 4 workstreams covering technical build, data migration, change management and testing. The student wanted some advice about how best to communicate risks and issues to senior management.
Here’s a summary of what we discussed.
Are there guidelines about what risk information should be reported to senior management?
No, not that I am aware of. The PMI Risk Practice Standard doesn’t include anything. The PMBOK® Guide talks about ‘Project Performance Reports’ but provides no detail as to what these should include. I think you’ll have to define the content of your reports yourself.
What should you include in a graphical risk management dashboard?
For a senior management report I would only report the open risks per project and/or open risks per category (scope, budget, schedule etc). This would let you see if there is one area like schedule that has a big risk impact on all projects.
I wouldn’t include:
- Total number of risks overall
- Closed risks
- Risks with an impact status of Low or Medium
This is because the senior management team can’t do much, if anything, with this information. The number of risks alone is pretty meaningless. Some may be very small, some projects may only have a few but they could be significant. A better way would be to report risk impact – what is the cost of all the risks if they happened?
The best approach would be to ask the key stakeholders what they are interested in seeing. I don’t think closed risks or number of risks is of any use as it doesn’t give them information they need to make decisions about the project. Risks by category, or risks with an impact rating of ‘High’ is more meaningful.
Should I show risk trends over the months?
No. What would the senior management team do with this information? At the beginning of the project you’ll identify lots of risks and then close some and open new ones. If you have a risk review meeting one month and identify another 50 risks this will skew the trend data. I would advise only showing a snapshot in time. You could use an arrow to indicate whether the overall risk profile of this project is going up or down, using a metric like whether there are more or less High risks or whether the cost implications for risk mitigation are going up or down.
What about reporting on issues?
For senior management, only show the high priority open ones. Typically I report also on ‘high priority closed this month’, then those issues drop off the report for the next month. This shows that you are making progress in resolving issues, even if new ones come along. If you don’t do this, your report could show that there are 20 open issues with a status of High Priority this month, and 20 next month. However, they could be 20 completely different issues! Without more detail, like issue names and descriptions (which, frankly, your sponsor is not going to want to wade through), your stakeholders will not know that you are dealing with issues and may assume that you are not tackling problems on the project.
As well as a graphical representation in a pie chart or dashboard, I would also include the top 10 issues in more detail – descriptions and action plans. If you need senior management input to resolve any issues make sure that these are included in the report and that you highlight where they need to make decisions.
Again, the best approach would be to ask your senior management team what they want to see. If they don’t know, present them with your graphs and report for a few months and then ask for feedback about what they think and what else they need to know in order to carry out their roles on the project i.e. decision making, governance and oversight.
Want more guidance on project reports? Get my Better Project Status Reports course here.
Copyright © A Girl's Guide to Project Management [Tips for risk and issue reporting], All Right Reserved. 2014.
- Respecting and trusting his players -- garnering responsible behaviors in return
- Allowing time for life beyond cricket, resulting in a fresh enthusiasm for both the training regime and the game
- Setting high expectations, but using a supportive style to encourage striving for excellence rather than demanding excellence
On 5 February we celebrated Jack’s first birthday. He was most excited by the gift of a push-along car, although it took him a couple of days to work out how to press the small button to get the music to play. Currently he’s lifting up the seat, putting plastic bricks in the recess under it and then taking them out again.
He did get another present – about 6am that morning I gave birth to Oliver, the latest addition to our family. He was a little early, and certainly wasn’t expected on that particular day. Luckily we had planned to have him at home so we were able to handle the family coming round later that day for tea, presents and birthday cake. The fact the two boys share a birthday makes me feel slightly odd, although they won’t know any different and I hope that they will come to appreciate sharing their celebrations with each other.
So at the moment the house is full of birthday and new baby cards, a sea of blue congratulations. We don’t have the surface space for them all, so I’ve strung them up from picture hooks. The next big project task is writing thank you notes for all the gifts the boys received, and again people have been very generous with their presents and we’ve received things from people we never expected anything from.
Having two babies in the house means I have to be even more organised than usual. If it isn’t on the calendar it doesn’t get done. We have a structured meal planner (although at the moment it’s mainly eating up food from the freezer that was prepared and cooked in advance as I knew I wouldn’t get much kitchen time when the new baby arrived). We have a lot of help from family, and we are coping on very little sleep, but that’s normal.
In terms of blogging, you’ll see a few more articles from people other than me, as I’ve called on the wider project management community to help me out with content over the next couple of months as I take a bit of time off to get to know my new family and rest up. Thanks for sticking with me over the last year as we adjusted to parenthood, and look out for more parenting stories as this year goes on!
Copyright © A Girl's Guide to Project Management [The Parent Project: Month 12 (or is it Month 1?)], All Right Reserved. 2014.
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)
- Systems Thinking - seeing the whole, the interrelationships between the parts, and the patterns that emerge from the interactions between the parts.
- Context Awareness - being mindful of the business governance processes, operational, economic, and technical influences and constraints of the domain in which the system operates.
- Accepting Uncertainty - by acknowledging the fundamental principle of all project work - statistical processes drive probabilistic behaviours in ways we may not understand and possibly cannot control. No solution is possible, only risk response in the form of risk retirement or margin.
- Complex Systems Evolve - based on the fundamental principles of the sciences of evolution, ecology, and adaptions, human built systems have the same results. Adaptation, self-organization, and natural selection are in play.
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.
- What is desirable?
- What is effective?
- What is feasible?
Outsourcing can be a great solution but is not the best solution all the time. Here are some key considerations influencing the outsourcing decision.
A number of factors specific to your own situation influence outsourcing. Here are some key considerations I have derived from others involved across a number of organizations:
- Degree of customization required – If a high degree of customization is required, it might be helpful to keep it in-house.
- When company needs to remain self sufficient – If there are competitors providing the product, if one disappears it will not effect your operations. If there are a limited number of competitors from which to source, you may want to bring it in-house.
- Business Mission Critical Function – Commodity or administrative tasks are better candidates for outsourcing, whereas items that are competitive advantages are better off done internally to reduce risk.
- Is function a core competency of the organization? – This is similar to the last one, but assesses whether you have the talent or resources in-house.
- Assemble components, build components from scratch, or outsource altogether – Assembling components is a lot easier than building them from scratch and often means that the components are commoditized. It puts the internal “customization” where it really matters.
- Speed – You need to evaluate whether speed matters, and whether an outsourcer can deliver it faster than you can internally. Opportunity cost of using resources on other projects needs to also be considered.
- Longevity of the asset – If the asset has a short lifespan, you may want to outsource. There will be little learned or developed of competitive value by building a short-term asset in-house.
- Supportability – If the asset requires a lot of support, you may want to outsource it – or, on the other hand, you may be forced to build the competency and in-source it!
This is not a complete list but includes some key considerations to get you thinking. The decision of whether or not to outsource is always an organization-specific issue, and there is no blanket answer for when to outsource or in-source. But there are a number of factors, some key ones outlined above, that can help you make the right outsourcing decision.
John Reiling, PMP
- Resource leveling, to be used when you have resource constraints or are aiming for more efficient and effective resources utilization
- Schedule crashing, for reducing tasks' duration by applying multiple or better resources to the same tasks
- Fast-tracking, to reduce the project duration by overlapping tasks that otherwise would have been sequential and dependent on one another
Last month I reviewed Brigitte Cobb’s book, Make It Fly: The step-by-step guide to make ANY idea, project or goal take off. And I have a copy to give away.
Want to read more about it before you enter? I interviewed Brigitte last month as well. You can read what she had to say about the book and her top tips for getting things done in the interview here.
Copyright © A Girl's Guide to Project Management [Giveaway: Make It Fly], All Right Reserved. 2014.