Planix

This summer we gave a presentation on simplifying the software estimation process for modern distributed systems. In it, we tried to boil down 10 years of thinking and experience on the subject; our goal was to make the process much more repeatable than it has historically been and as simple as is appropriate. On this particular day, a colleague from a client of ours approached me after the formal Q&A period and asked a question that demonstrated the level of hard-won expertise and critical thinking about estimation and project management she possess.

To paraphrase, she asked “I’ve developed my own techniques to estimate how working on multiple projects impacts a person’s productivity, what are your thoughts and references on the topic?” In essence, the topic of this question is what we, ALTERthought, call the switching gears factor. She inspired this post.

While the topic may seem tangential to the most important aspects of estimation and project management, it is, infact, one of the major reasons projects go over budget and off schedule. In the last 10-15 years, the popular notion of “multi-tasking” along with “doing more with less” have become culprits in causing teams to overload their professionals with multiple projects. This naturally impacts how effective a person is on any particular project. For many years, we’ve represented this concept as the productivity factor and have used it as a central tennant in project planning and estimation. It is so critical in planning, that we’ve codified it as a key variable in Planix, our Software estimation and planning tool

This, that, the other
Switching gears is not the common mistake of cramming excessive work into a shortened time frame, but the realiity of asking people to perform activities on a variety of different projects. Team members of different stripes can all relate to wearing not just different hats, but different hats for different initiatives. The software developer is asked to work on a new feature for an existing application, design for a completely new application, and bug fixing for an existing application, all contemporaneously. The project manager is asked to manage one project, perform business analysis for an upcoming project, and document the proceedings of the meeting for a third, maintenance initiative. The marketing manager is asked to survey customers for a recently released application, perform user acceptance testing for one in the pipeline, and to develop requirements for another.

Cry me a river
There is a strain of the business culture that would take the paragraph above as whining and the bemoaning of someone who strives for a project management utopia. Ahem. Where there is nobility and truth in the effectiveness of the American work ethic, there is delusion in the premise that every project is a high priority and will be completed as planned. In short, there is false optimism in thinking that we can have our cake and eat it too. It is precisely in response to realities such as the costs of multi-tasking and the rantings of the captains of “do more with less” that the Agile and eXtreme programming methodologies have increasingly gained in popularity. These approaches are fact-driven and deal with the reality of the company’s environment. Too many projects? Disparity in developer capability? Weak requirements? Overloading of team members? It all gets reflected in the concept of velocity.

The multi-tasking myth
It is true, that in modern American corporations, small and large, we all are and will continue to be asked to achieve “more with less.” What is not true is the common wisdom that simply asking for multi-tasking means people will accomplish more. Infact, social commentators, science and emerging popular coverage on multi-tasking demonstrate that multi-tasking means lost productivity – especially as the number of interruptions or activities increases. A relatively recent Vanderbilt brain imaging study (PDF file) demonstrates that as the time between interruptions decreases, the time required for a person to recover from the context switch and become productive again increases. We argue that this finding is analogous to and a by-product of increases in the number of projects assigned to a person. In common sense terms: As people are interrupted more, they get less done.

What does this mean for my project ?
Referring back to the original question posed by our colleague and client, a handful of people have analyzed how multiple assignments to any one individual costs an initiative and how to reflect it in project scheduling. Among the most notable is Gerald Weinberg (“Jerry”). In his classic book, Quality Software Management: Systems Thinking, Jerry proposes a rule of thumb for accounting for the context switching costs of working on multiple projects. Jeff Atwood’s blog, Coding Horror, gives a good summary of Jerry’s rule of thumb, so I won’t try to recreate it here.

Aside: for what its worth (its worth a lot) Jerry also takes a very sober – and sometimes critical view of our profession, consulting, in this book.

Shoulders of giants, math for you
Building on Jerry’s rule of thumb and the research from Vanderbilt, we propose our own rule of thumb that affords project planners an equation to quantify what working on multiple projects does to a person’s productivity.

Baseline Productivity
First, we build on our experience and existing research on productivity as an expression of productive hours worked in a week.

1. The normal work week consists of 40 hours
2. The most productive companies/people in the world are 80% productive;
3. This is usually an outcome of life and the realities of a modern company: responding to e-mails, bathroom breaks, picking up the kids early from school, sending your rare burger back to the kitchen during a 2-hour lunch, doctor’s appointments—you get the idea
4. So, what we have in world-class organizations is 32 productive hours per week (40 hours * .80)
5. This productivity factor clearly will vary by the experience level of the professional involved
6. You should adjust this productivity factor to represent the reality of your organization

That being said, this is an important departure from Jerry’s baseline assumption of 100% productivity (ie, 40 hours worked = 40 hours productive). Its also the basis for being able to construct a simple equation for modeling what happens to productivity as projects are added to a person’s plate.

Switching Costs & the productivity factor
If the most productive organizations and people in the world acheive 80% productivity on single projects, what happens when they begin to work on multiple projects? We propose and have observed the following: if your team members can achieve X% productivity on any single project, the cumulative effect of adding additional projects can be represented as a product of the productivity of the total number of projects to which they are assigned. So if x = a person’s productivity percentage on any single project and n=the total number of projects to which they are assigned, their total productivity can be reprsented by X% raised to the power of n.

Using our example of an 80% productivity factor, the equation Xⁿ would yield the following chart of productive versus context switching time for 1 – 8 projects.

Looking at it a different way, with world-class, 80% productivity, the point at which a top-notch professional begins to spend more time context switching rather than being effective is at approximately 3 projects.

A Calculator
To calculate exactly how much productive versus context switching time occurs based on the total number of projects a person is assigned, use this calculator we created in Google Docs. Feel free to save your own excel copy (File > Export > .xls). The key variables you can change are as follow:

1. Productivity factor (eg, 70%, 80%, 90%, etc)
2. The number of simultaneous projects to which a person is assigned.
3. he total work hours for an individual in a week (we recommend you be judicious about being overly optimistic of people being able to work more than 40 hours per week)

That’s it. Now, when negotiating with business stakeholders, hopefully, you’ll be able to more effectively demonstrate and account for the costs of assigning team members to multiple projects.

On Wednesday, June 18th, I had the honor of presenting our approach to software estimation at the Central Virginia Chapter of the Project Management Institute. Hard-won over the past 10 years, it helps unite both plan driven and agile approaches for estimating software development projects. Owing to serendipity (and 10 years of preparation), overall the approach and presentation appear to have been relatively well-received. Our approach blends academic theory with real world expertise and is, infact, embodied in our product, Planix. In truth, we've developed and customized these approaches while standing on the shoulders of giants such as Barry Boehm. We've focused on distillation and the ability to (in some cases) enter fact-based negotiations in under a day (honestly). One of the key objectives of the process is to quickly get to a point of being able to negotiate functionality, schedule, and cost with your customers. The abstract for the presentation is as follows ...

Software estimation continues to be a daunting process. Traditional plan driven approaches are being usurped by Agile-oriented methodologies. While the Agile Manifesto and Lean concepts are an important toolkit for the day-to-day management of a project, designed to help a team tune itself to its own capabilities and productivity over the life of the project, the application development estimation process still continues to be a dark art. Project Leadership must still answer to those more senior in the organization and those leaders must still answer to the market and investors. Often times, the question they ask is, 'When will it be done?' Ultimately, this becomes the seminal question for organizations eager to increase revenue through the marketing of new capabilities.

In this presentation, we've tried to provide some glue and distill some powerful concepts which can allow teams to rapidly enter negotiation with business customers regarding functionality, schedule, and cost. This seminar is focused on helping analysts, architects, and project managers become more confident using rapid and accurate estimation and planning skills. It serves to bridge the gap between Lean/Agile approaches and the more intensive forecasting needs of organizations of various sizes.

The presentation is presented below. For more info, or to see it live contact us.

The full seminar is focused on helping analysts, architects, and project managers become more confident using rapid and accurate estimation and planning skills. The seminar serves to bridge the gap between Lean/Agile approaches and the more intensive forecasting needs of organizations of various sizes. Participants will:

1. Understand the basic structure of a business requirement
2. Learn to listen for keywords in order to help organize the suite of requirements
3. Gain an appreciation for basic use cases and user stories
4. Obtain a basic overview for the use case point methodology for software
5. Appreciate how to frame scope negotiation on a feature-by-feature
6. Appreciate the power of architecture and design in work-planning
7. Appreciate the power of what-if scenarios for estimates

Barry Boehm is an undisputed giant in the field of software engineering. His work has been instrumental in many advancements in the field. Perhaps his most lasting contribution is his modelling of the economics of software engineering. Boehm’s work has been an inspiration for our team and many others like us for many years. The International Conference on Software Engineering will be honoring Mr. Boehm in Minneapolis.

From the conference overview :

Many people have contributed to the establishment and growth of the field of Software Engineering. Not many people, however, have consistently made significant contributions over a 40-year time period and earned respect across academia, industry, and government audiences. Barry Boehm’s work has impacted Software Engineering tremendously, and he continues to be very active. However, Barry is approaching semi-retirement, and the purpose of this symposium is to highlight the legacy of Barry through the gathering of colleagues, friends, and members of the Software Engineering community.

Yesterday, Chris Kanaracus at Redmond Developer News” honored us with coverage in the April Issue. If interested, you can read the full article here.

Early this morning we began offering paid plans for Planix. We hope our users will find value through this introductory pricing. The information is available here. We look forward to your continued feedback and are busily engaged in developing upcoming features.

We will be upgrading our servers tonight to support SSL in preparation for our eventual 1.0 release. We plan on doing this at 11pm EST, tonight.

Our apologies in advance for any inconvenience; we are close to offering Planix for subscription!

After more than 4 months in Private Beta, we’ve decided that its time to open up the application for broader usage. We hope to obtain additional feedback in order to continue to refine functionality and usability . In the spirit of continual improvement and refinement, we look forward to your comments and to releasing the application in earnest in the coming few weeks. The team has worked diligently to arrive at this milestone and are excited about the emerging set of features we’re exploring. Thank you all again for your continued support, and please honor us with your continued constructive input.

Recently, we’ve been fortunate enough to receive additional coverage from a couple of sources, lately. Chris Kanaracus at Redmond Developer News covered Planix in a blog post on February 28th. Today, Brian Benziner at Solution Watch also posted a review of a handful of Project Management software applications in addition to Planix including: Basecamp, Plan HQ, Competitous, Unfuddle, and Gilffy. We look forward to reviewing these services ourselves in the coming weeks.

Our Private Beta continues to progress well; we thank everyone for your positive as well as constructive feedback. We’re excited about the new features and functionality that you’ve inspired and that we have been exploring. Also, we were fortunate to have received some favorable coverage this week. Pete Cashmore of Mashable was kind enough to Review the application. As a result, a fair number of people have requested access to the Private Beta. We’re currently handling those requests on a case-by-case basis. Thanks for all of your continuing support, and look for more, soon!

Since our initial beta launch we’ve received a range of input regarding the application. One of the first things you’ll notice is that we’ve changed the name of the product based on your feedback. We’ve reverted back to the original name of the application, Planix as a result of your suggestion that using the previous name was confusing. We’ve also responded to other suggestions and have put together other features which were already on the product plan. In summary, the changes include:

• New estimate amendment feature – allowing developers to comment on and suggest new estimates
  • For now, you can request special user access to enable developers to access this functionality
  • In the future, you will be able to manage users within your team by yourself
• New business priority worksheet – allowing stakeholders to prioritize the use-cases
• User Interface speed enhancements
• The expand/collapse state of the various User Interface sections is now “remembered” as you navigate through the application
• Technical and Environmental factors options are now more descriptive and configurable

In the New Year, we’ll be launching the application to the general public. In the meantime, we continue to take suggestions from our users and to plan the product’s evolution. So, don’t be shy, and please provide your on-going support and suggestions.

We thank you very much for your support since the initial beta launch, it is very much appreciated. We all wish you a very happy holiday season and a very happy New Year!

At last, Planix launches after weeks in alpha release, months in development, and years in the making. The questions it tries to address are two we’ve seen in all shapes and sizes of organizations and projects: “When will it be done?” and “Are we on track?” The ‘it’ here is a custom software application. Software estimation is part art and part science. While we don’t claim to have cracked the secret code to software estimation with Planix, we do hope we’re well on our way to ‘democratizing’ the seemingly arcane process for everyone.

Planix leverages the best practices and concepts provided by estimation frameworks such as COCOMO (COnstructive COst MOdel), Function Point Analysis, and Use Case Points while sprinkling in a handful of our own successful techniques for estimating, planning, and negotiating the development of software. While these best practices are incredibly powerful, historically, they’ve been hard to implement in a repeatable way because of their complexity. Our goal with Planix is to empower teams by finding ways to make estimation and project management understandable without requiring them to have a PhD in software estimation or Microsoft Project.

With the release of this Private Beta version we hope to get crucial feedback to refine the application before our public release. We recognize this is a living application that will continue to evolve, and we have a queue of both refinements and new features which we are already actively managing. We thank you for taking us up on our invitation, and look forward to your input.

Please email any input you do have to feedback [at] planixonline.com

Happy estimating.