PM Blogs Network

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.

Who pays for the estimates for jobs you don’t get?

• 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.

How much extra do you need to “pad” the work for the ”unknowns”? Why should your customer pay for that?

• 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.

Are you going to give a range?: “It will cost you no less than this but no more than that”.  Will you guarantee that?

• 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.

If it costs you more to make the software than you estimated, are you willing to take the loss? Why??? If not, how will you deal with that? Re-negotiate the contract?

• 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.

How do you know enough about the work to be able to give a reasonably accurate price/estimate?

• 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.

If a competitor shows them a better way, will they ever come back to you again?

• 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.

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

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.

Related articles

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 practitioners often get bogged down in the details of getting a project done at all costs. This can cause us to make decisions and take actions that we later regret, because they compromise our position as leaders within our organization. There are three leadership skills that we as project managers need to cultivate in ourselves and that should be non-negotiable, no matter how difficult the project.

1. Integrity: It is easy for a project manager to compromise and make decisions that are in the gray area between right and wrong. To be a strong project leader, it is important that you show character in your decision-making process. Even if compromising your principles makes the current project go more smoothly, in the long run you will lessen your effectiveness as a leader. And remember that your actions as a leader have a huge effect on your team -- if you are willing to cut corners or compromise your decision-making, how can you expect any more from your team? Maintain your integrity by setting clear operating principles for your team at the start of the project and always acting within those principles throughout the course of the project, even if it is difficult. 

2. Adaptability:As project managers, we have really strong methodologies and standards that drive our planning, implementation and review processes. And sometimes, it's easy to allow those methodologies to hamper flexibility. To be a great leader, you have to be comfortable knowing the methodology and have faith in your understanding of the methodology and your decision-making process. At the same time, you need to be flexible enough to change with the dynamics of a project. These dynamics can play out as the project unfolds: when resources are limited after allocation; a sponsor or key stakeholder makes new demands; or even having to stop work on a project because it no longer fits into your organization's strategic goals. In these cases, rely on the solid plan that you developed earlier, but be willing and able to change or scrap that plan when it doesn't fit the new circumstances.  

3. Judgment:Project managers will spend the bulk of their time acting as communicators between sponsors, stakeholders and the team. With all of this communication comes a ton of information, and a project manager must have the confidence and judgment to act on or discard that information. Beyond communication, you'll make decisions that will affect not only all stakeholders, but also your business and your organization's overall performance. Two really important points here. First, you have to be patient because big decisions don't come every day and when they do, you have to be bold enough to take action. Second, you also have to work within your organization to garner the trust necessary to make decisions and, more importantly, to make mistakes along the way. The learning curve isn't a straight line, and you need the support of your sponsors and supervisors to get the necessary experience in decision-making. Because at the end of the day, that's what judgment is all about: experience. 

By making these skills the core of your personal leadership development process, you can make all other project decisions with the clarity and confidence you need to move your project toward a successful conclusion.

What are your must-have leadership skills?

Find out what other skills you can sharpen to help your organization succeed in PMI's 2014 Pulse of the Profession^®.

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.

Risk Management

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.

Cost Modeling

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.

Performance Measurement

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? 

Conclusion

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

There are several fundmental principles of writing software for money. Let's start with the prime directive.

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.

1. 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.
2. 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.
3. 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.
4. 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.

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

Voices on Project Management guest blogger Michael O'Brochta, PMI-ACP, PMP, has worked in project management for more than 30 years. He has led programs to mature project management at the U.S. Central Intelligence Agency and at consultancy Zozer Inc., through which he helped develop and implement a new government-wide Federal Acquisition Certification for Program and Project Managers. He writes and speaks extensively about ethics and project management. Since climbing another of the world's Seven Summits, Mr. O'Brochta has been exploring the relationship between project management and mountain climbing.

Professions are characterized not only by the products and services they provide, but also by the behavior of their membership. Organizations that stand the test of time tend toward ethical conduct. While there are multiple ways to learn ethical conduct, consider the method recommended in this passage from a book's foreword:

"The thing that can be done is to introduce into every public school a simple textbook of ethics, and drill it into every child from the youngest to the oldest. The little book should present the principles of the moral conduct in the clearest and simplest manner; that is, the fundamental ideas of right and wrong, the proper relations in the family, or parent and child, of the young to the old, of inferior to superior, of the employer to the employed, the citizen and the state -- the duties in all their relations, as well as the rights. We may then get back a little reverence in place of the growing bumptiousness and smartness."

Note that the foreword was written by Charles Dudley Warner for Benjamin B. Comegys' Primer of Ethics, published in 1890. In other words, old is new in ethics. Ethics are timeless, and our need for them is as well.

Organizations at the forefront of ethical best practices create a climate of awareness with clear expectations. This climate can be created through persistent and consistent communications about the preferred behavior and the consequences of the undesirable behavior. It can be bolstered by providing guides and aids for employees to use -- something to establish, model and reinforce the norms of ethical behavior. And it's important that ethical behavior in an organization be established in a clear and straightforward manner at the earliest outset of an employee's tenure there.

Organizations that do ethics well also provide support for employees and stakeholders when dilemmas arise. They do so by making available their ethics code of conduct, ethical decision-making aid and a forum for the advancement of ethics-related topics.

With help from the Ethics Member Advisory Group, PMI actively seeks to learn about ethical best practices and adopt ones that are most suitable for the Institute -- and for the profession.

If you haven't reviewed them recently, revisit PMI's Code of Ethics and Professional Conduct and Ethical Decision-Making Framework, and visit the Ethics in Project Management Community of Practice.

Shim Marom provides thought provoking posts. This one was a perfect straight line requsting a respons

1. 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.
2. 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.
3. Do estimates stifle creativity and kill innovation?
4. Do people need estimates? And if so, why?
5. Is the very act of estimation results in the creation of uncertainty?
6. Is estimation a practice still hanging over from the Waterfall era?
7. Is No Estimation better than Bad Estimation?
8. Is  Estimation really just a form of Guessing?
9. Are estimates necessary for Governance? Is it reasonable to require estimates for the purpose of pacifying governance needs?
10. 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?
11. Is costing a necessary tool for determining business value?
12. Does the scope drive the budget or does the budget drive the cost?
13. If estimates are required in order to support decisions, can decisions be made without estimates?

The AMACOM Book Performance-Based Project Management has a blog post from the publisher.

The book can be purchased from the link under the cover to the left. 

People talk about motivation, work-life balance and developing a productive team. But only a few realize the importance of happiness within this equation. 

Look no further than the recent cricket matches between England and Australia for a very interesting case study of the effect of leadership and morale on sustained team performance.

I'm not going to explain cricket other than to highlight that it's a team game and that each test match takes up to five days, with six hours of playing time each day. It requires sustained concentration, and outcomes are significantly influenced by the collective expectations and attitude within the team. Unlike many sports, a single star cannot make a huge difference without support from his teammates and the playing time resembles that of a normal workweek.

In parts of what was once the British Empire, the game of cricket reigns supreme. One of the sport's major contests is the series of five matches between English and Australian teams every couple of years for "The Ashes." The outcome of each of the five series is of significant national importance -- defeating the "old enemy" makes headline news in both countries. 

Unusually, in the last nine months, there have been two series played: the first in mid-2013 and the second in the current Australian summer. England won the first series 3-0. And after losses in India and England, the Australian team was written off as "the worst ever" by the local press. But then Australia won the second series 5-0, a feat only accomplished twice before in Ashes history, and now they're national heroes. What caused the change?

The difference wasn't in the skills of the players or the support staff (they were basically the same). It was the team's attitude. Prior to the start of the English series, Australia focused on peak performance at all costs. There were rules, curfews and strictly enforced discipline, which led to dissent, internal divisions and disenchantment. 

The Australian Cricket Board decided a change was needed and appointed Daren "Boof" Lehmann as the new team coach just 16 days before the first English test. The change was too late to make much of a difference in the England series, but by the time the Australian series started, Mr. Lehmann's philosophy had made a fundamental -- and enduring  -- change in the Australian team culture. 

With Mr. Lehmann at the helm, every team member is committed to team excellence. And rather than training drills for the sake of drills to drive performance, players want to improve and develop. The drive is intrinsic, not extrinsic. The most often repeated comment among team members is, "Lehmann made it fun again!"

The Australian team members are happy, taking genuine delight in each other's successes as well as providing support and encouragement when things don't go as planned. 

This transformation will undoubtedly be the subject of research in years to come, but my initial impressions of the key skills Mr. Lehmann has used are:

• 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 

Applying these techniques takes courage (especially under the glare of national publicity). This is the challenge for any leader -- building a champion team that enjoys its work and challenges. 

Applying these techniques takes courage (especially under the glare of national publicity). Building a champion team that enjoys its work and challenges is the challenge for any leader, particularly if you want your team to help you push your project through to a successful conclusion. 

How do you make your team's work fun when you need high performance?

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.

 

 

In my last post, we discussed the five basics of a PMO implementation plan. Here, I'll delve deeper into those five: 

1. Current State Assessment

When assessing the current state, it might be helpful to hire an external consultancy, as internal initiatives may lose momentum along the way. The people internal to an organization might not be able to ask the right questions or they might even resist due to a fear of change. An external consultancy can assist in overcoming political issues by adopting a structured approach. Usually, consultants force or drive change because that's what they are hired to do. In the end, a good diagnosis will point out issues and opportunities for improvement. 

2. Future State Vision

Based on the assessment, it is possible to design a future state vision, describing how projects, programs and portfolios should be managed in order to fulfill organizational needs. That's because when the current state is clearly understood, it is easy to compare to benchmarks. Consequently, the organization can realize what is missing or what is done but could be improved. Ultimately, the future state vision details exactly what the organization wants to become.

3. Gap Analysis

The next step is to carry out a gap analysis by comparing the current state to the future vision. This analysis has to focus on three factors: 

• What is desirable? 
• What is effective?
• What is feasible?

A successful gap analysis clearly identifies what is missing or what could be improved, prioritizing which features, processes and structure the PMO should have, according to effectiveness (cost x benefit), desirability (sponsorship; what the company want to implement) and feasibility (what is realistic and what is possible to do). We have to select and prioritize based on cultural and organizational feasibility, not only based on resources available.

For example, imagine an organization wants to implement enterprise project management (EPM) software. There are plenty of options in the market. Some have fancy features and are more expensive. It might be desirable to have top-notch software, so we won't have to substitute or upgrade it for years. However, it is effective to choose software that offers the simplest solution and satisfies future state needs. Finally, it might be feasible to start with familiar software to overcome people's resistance and rejection to the PMO implementation.

In this particular case, project professionals might desire the best EPM in the world (desirability) -- but the company could do well with a free version or simpler software (effectiveness). Finally, considering that people unfamiliar with project management practices will have to use the software, it might make sense to get something familiar or similar to other software they already use (feasibility).

4. Implementation Strategy

After the gap analysis, introduce stakeholder requirements to define the implementation strategy. I recommend thinking of the PMO like a new business unit or a small new company. The PMO should have its own mission, vision and goals. We have to identify who are its stakeholders and customers, so we can define its value proposition and its services. Personally, I use the Business Model Generation canvas to do that.

The implementation strategy defines the approach to implement a PMO, major expected results and the overall framework, considering organizational strategy and corporate project management governance. Consequently, the PMO business model must support and enhance strategic alignment by selecting, prioritizing and managing portfolios of projects that sustain and boost organizational strategy.

5. Implementation Plan

Finally, the implementation plan is the detailed project management plan for implementing the PMO. While the implementation strategy is the approach chosen to implement the PMO, the implementation plan puts that strategy into action. 

We start by defining its scope and work breakdown structure. Then we create a schedule of tasks to deliver the project scope. Resource needs are identified and a budget is set. Other subsidiary plans are created to manage integration, scope, time, cost, quality, communications, human resources, risks, procurement and stakeholders. 

The implementation plan should be as detailed as you need. I want to emphasize the importance of defining a business model for your PMO, allowing for performance measurement and improvement after the implementation. 

In my next post, I'll provide a framework for sustaining and improving your PMO, once it is set up and running. Do you have any tips or examples of PMO implementation plans? 

For more on PMOs, check out the PMI^® Thought Leadership Series: Strategic Initiative Management - The PMO Imperative.

The project schedule plan is probably one of the most important project management assets a project manager has to develop, maintain and manage throughout a project. Why? Because compared to other planning documents -- such as the resources plan, costs plan or risk management plan -- a project schedule will generally have widespread visibility within the project's environment and among stakeholders.


For instance, your project sponsors will want to see your project schedule and understand whether you are on track to deliver it on time. The beneficiaries of your project will want to see it to understand your next deliverables or key milestones. Your core project team will seek it out to find out how work activities are planned and relate to one another, and how resources are allocated. And, probably most important, you as the project manager will need it to be your map throughout the project, guiding you to drive the project to its target. 


Now, if your project schedule is incomplete or flawed -- for example, it's missing work tasks or it features wrong dependencies between project tasks -- you will most likely steer your project into a wall. And even if you put everything right into it (i.e., all work activities, the right durations, right resources assigned, right dependencies), that still might not be sufficient for a successful delivery. That's because, as you know, a project schedule is not a linear sequencing of work tasks that perform exactly as initially planned. 


In addition, your project schedule will be subject to the project's challenges and constraints, such as resources scarcity, work overload, aggressive milestones or delays. It's these unexpected or imposed factors that will constrain your project schedule and demand that you react quickly, applying various tactics and techniques, to adapt the project schedule and make it ultimately work.


There are several techniques that can help in analyzing, adapting and improving a constrained project schedule. Among these, three stand out for their effectiveness:


1. Resource leveling, to be used when you have resource constraints or are aiming for more efficient and effective resources utilization 
2. Schedule crashing, for reducing tasks' duration by applying multiple or better resources to the same tasks
3. Fast-tracking, to reduce the project duration by overlapping tasks that otherwise would have been sequential and dependent on one another

In my next post, I'll dive deeper into what these three techniques are, when to apply them and how to do so.


How do you manage constraints to your project schedule?