Skip to content

Feed aggregator

5 Reasons Why Projects are an Essential Tool for Better Business

Better Projects - Craig Brown - 8 hours 30 min ago
The #NoProjects book at InfoQClick this image to get a PDF booklet on
the argument for #NoProjectsThis article is an inoculation against the #NoProjects meme.

Projects are great. Despite the cry on the web about projects being bad for business they can really help you do a better job of organizing your work.

I am writing this as a counter to a meme about why projects are evil and need to be abolished. What was once a sentiment is now a movement (with it's own hashtag, so it really is legit.)

The main arguments against projects seem to be;

  • Projects are temporary organisations. People that work on projects don't have to live with the consequences of the work they do, and so will eagerly take quality shortcuts that someone else is going to have to pay for
  • Projects are organised around impossible goals. Some executive somewhere wants a new product out to market, or internal process fixed and all the big decisions about time money and scope are done before you arrive. 
There are more, but they are essentially minor next to these two complaints. 
So, drumroll please.
Read more »
Categories: Blogs

Decision Making in the Presence of Uncertainty

Herding Cats - Glen Alleman - Sat, 06/25/2016 - 23:44

There's another rash of Twitter posters supporting the conjecture that decisions can be made about how to spend other people's money without estimating the impact and outcome of that decision. This is a core premise of #NoEstimates from the Original Poster

No Estimates

Here's a starting point to learn that simply not true 

There are 100's more books, papers, conference proceedings on the topic of decision making in the presence of uncertanty.

It comes down to a simple concept

All project work is uncertain. Reducible uncertainties (epistemic) and irreducible uncertainties (aleatory). When money is being provided to development software, those providing the money a reasonable expectation to know something about when you will be providing the value in exchange for that money, how much money will be required to provide that value, and what capabilities will be provided in exchange for that money. The field of study where these questions and answers live is microeconomics of decision making. Software development decision making is a well studied subset of that field.

When it is conjecture decisions can be made in the presence of uncertanty without estimates - like the Original Poster did, and there is no supporting theory, principle, practices, or evidence of how that can be done - run away - it's a bogus claim. 

Related articles Making Decisions In The Presence of Uncertainty Essential Reading List for Managing Other People's Money Herding Cats: Decision Making in the Presence of Uncertainty Herding Cats: Thoughts on Suggestions That Violate Principles of Finance, Probability, and Statistics Making Conjectures Without Testable Outcomes
Categories: Blogs

#NoEstimates Book Review - Part 1

Herding Cats - Glen Alleman - Sat, 06/25/2016 - 01:17

I've started reading Vasco's book #NoEstimates and will write a detailed deconstruction. I got the Kindle version, so I have a $10 investment at risk. Let's start with some graphs that have been around and their misinformation that forms the basis of the book.

The Chaos Report graph,is the 1st one. This graph is from old 2004 numbers. That's 12 year old numbers. Many times the books uses 12, 16, even 25 year old reports as the basis of the suggestion that Not Estimating fixes the problems in the reports. The Chaos reports have been thoroughly debunked as self selected samples using uncalibrated surveys for the units of measure for project failure. Here's a few comments on the Standish reporting process. But first remember, Standish does not say what the units of measure are for Success, Challenged, or Failure. Without the units of measure, the actual statistics of the projects and the statistical ranges of those projects for each of the three categories, the units as essentially bogus. Good fodder for selling consulting services or for use by those with an idea to sell, but worthless for decision making about the root cause of Failure, Challenged, or even Success. Any undergraduate design of experiments class would have all that information in the public. 

So the 1st thing to read when you encounter data like this is Project Success: A Multidimensional Strategic Concept, Aaron J. Shenhar, Dov Dvir, Ofer Levy and Alan C. Maltz. Only then start to assess the numbers. Most likely, like the numbers in the book, they're not credible to support the hypothesis. Which by the way there is no hypothesis for you can make decisions in the presence of uncertanty without estimating

So let's look further at the difficulties with Standish and why NOT to use it as the basis of a conjecture

A simple google search would have found all this research and many many more. I get the sense V didn't do his homework. The bibliography has very few references to actually estimating, no actual estimating books, papers, or research sites. Just personal anecdotes from a  set of experiences as a developer.

The Standish Report failure mode is described in Darrell Huff's How to Lie With Statisticsself select the samples from the survey. Standish does not provide any population statistics for their survey.

  • How many surveys were set out?
  • How many responded?
  • Of those responding, how many were statistically significant?
  • What does it means in terms of actual measures of performance to the troubled?
  • If the project was over budget, was the needed budget estimate correct?
  • If the project was late, was the original schedule credible?

None of these questions are answered in Standish reports. No Estimate picks these serious statistical sampling error up and uses the, as the basis of the pure-conjecture that Not Estimating is going to fix the problems. This would garner a high school D is the Stats class.

Screen Shot 2016-06-24 at 2.08.13 PM

Next comes a chart that makes a similar error. This reference is from Steve McConnell's book, but is actually from another source. The No Estimates book does a poor job of keeping the references straight. It is common to misattribute a report, a graph, even a phrase. The book needs a professional editor.

The graph below is used to show that estimates are usually wrong. But there is a critical misunderstanding about the data.

  • It starts with a straight line called perfect accuracy/. First there are two attributes of any estimate. Accuracy and precision. There is no such thing as perfect accuracy in the estimating business. An estimate is an approximation of reality.
  • The sample projects show they did not meet the perfect accuracy - whatever that might have been. This knowledge can only be obtained after the work has been done. Either at the end or during the project - cumulative to date
  • But there are two sources of the variances of estimates and actuals

Screen Shot 2016-06-24 at 2.08.06 PM

I'm in the early parts of the book and already have a half dozen pages of notes for either fallacies, incorrect principles, 30 year old references, and other serious mistakes on understanding on how decisions are made in the presence of uncertainty. My short assessment is 

It's a concept built on sand.

Related articles Myth's Abound All Project Numbers are Random Numbers - Act Accordingly The Failure of Open Loop Thinking How to "Lie" with Statistics Statistical Significance How to Estimate Software Development Capabilities Based Planning IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing Making Conjectures Without Testable Outcomes
Categories: Blogs

How to Guarantee Failure in Your Agile DevOps Transformation

Tasktop Blog - Fri, 06/24/2016 - 20:45

Many organizations make the same mistakes when it comes to scaling Agile and DevOps and then attempt to rectify those mistakes by formulating a new strategy—only to miss the real reasons why the initiative failed.

As someone who helps companies through software delivery transformations, I’ve seen my share of ineffective behaviors. What I find most difficult to watch is organizations that make the same agile and DevOps scaling mistakes year after year.

Recently I made a visit to a Fortune 100 company where the last two VPs responsible for the transformation had been let go. In the meeting, I took some notes about what might be happening to the company’s Agile and DevOps initiatives to get them into such a bad state. I had a vivid image of a billion dollars wasted, and billions more that would be wasted if they didn’t learn from the past. This lead me to create a set of anti-patterns that you want to avoid at all costs.

You can read more about the anti-patterns – the mistakes made by large organizations during Agile DevOps transformations – in my article published in CMCrossroads: How to Guarantee Failure in Your Agile DevOps Transformation.

And if you have questions or would like to discuss my findings and recommendations, leave a comment and I would be happy to discuss.


Categories: Companies

Are Project Boards Really Kanban? How Old-School Project Management Prevents Continuous Improvement

LeanKit Blog - Fri, 06/24/2016 - 19:55

Project boards limit your visibility into your team's capacity and performance. Learn how team Kanban boards enable continuous improvement.

The post Are Project Boards Really Kanban? How Old-School Project Management Prevents Continuous Improvement appeared first on Blog | LeanKit.

Categories: Companies

#OrganizedWithPride: Celebrating Asana’s LGBTQIA community

Asana Blog - Fri, 06/24/2016 - 18:12

06_15_Pride_Article Header

As we celebrate Pride this year, we’d like to take a moment to reflect upon the recent tragedy in Orlando. Our hearts go out to the victims and their families, friends, allies, and communities.

Now more than ever, we each have an opportunity to be an ally. In doing so, we can encourage compassion, kindness, and love—not just in the LGBTQIA community, but in every community to which we belong.

Employers should be allies. By providing a hiring and working experience in which all people feel they are equally respected and valued, regardless of gender identity or expression, sexual orientation, religion, ethnicity, age, ability, citizenship, or any other aspect which makes someone unique, companies can contribute positively to this equation.

Employers should be allies. #organizedwithprideTweet

Asana strives to be the change we want to see in the workplace, and that is one which is radically inclusive. As we prepare to celebrate Pride this weekend, we’d like to highlight the members of the LGBTQIA community who are part of Team Asana, and take a look at how we can all create a more diverse, inclusive, and inspiring company.

We sat down with Ashley, Elden, Emilie, Josh, Patrick, Rachel, and Tim to talk about education, support, and empowerment at the Asana office.

Creating a more LGBTQIA-inclusive environment Educate

“Being inclusive is about education and openness to learning about the constant evolution of identity,” Josh explains. “By being curious and open, you can show any diverse group or minority that you support and would like to learn more about them.”

“Even though I’m part of the LGBTQIA community, I can always be educating myself about the experiences of others in the community,” says Emilie from the marketing team. “For example, I know and understand so much more about the transgender, genderqueer, and gender-nonconforming experience than I ever did before some of our dynamic and enlightening all-hands sessions on these areas here at Asana, led by community experts such as Mordecai Cohen Ettinger of CIIS.”

Support LGBTQIA Employees

There are lots of ways to support all employees, from company infrastructure to day-to-day interactions. Inclusive benefits and facilities, such as gender-inclusive bathrooms and insurance that covers mental health care and all parents, endeavor to provide support from which all employees can benefit. We also encourage people to become aware of preferred pronouns, and recognize unconscious biases and assumptions that might arise around language. Elden (they/them/theirs), a member of our engineering team, notes that “when companies encourage introducing pronouns, it’s great. I’ve had a lot of people here [at Asana] ask me if I wanted them to introduce my pronouns, which I find really helpful and welcoming.”


Empowering employees is an essential part to creating an inclusive environment. Asana has “a unique organizational structure that empowers all people to contribute and be heard across projects and teams, essentially allowing individuals who have different gender identities or backgrounds to speak up in places they might not have always felt so comfortable to do so,” says Ashley, our web analytics lead. Rachel, an engineer, adds that “noticing when people are passionate about something and giving them the space to champion their passions, such as diversity in recruiting, further empowers them.”

Empowering employees is an essential part to creating an inclusive environment. #organizedwithprideTweet

In addition to empowering employees, building a supportive environment and culture of learning from mistakes is important to allow for growth, says Tim from the recruiting team. At Asana, “we’re often of the opinion that it’s even better for someone to take on more challenges after they’ve made mistakes, because they’ve learned from them.”

Be open and communicate

Openness and communication with all groups lead to an increasingly transparent and inclusive environment. We focus on fostering openness in our work environment, personal lives, and within our product. At work, “our leadership training gives people the space to be vulnerable with their emotions, building in a support system because we all go through the training,” says Josh. According to Ashley, we “put a lot of effort into getting to know each other beyond just work interactions through team off-sites and meals together. They give us spaces to get to know co-workers as humans, which creates a really friendly, supportive atmosphere.” Tim feels that “the heart feature in Asana helps people show support and be encouraging. In email, unless someone actively responds with support, it doesn’t get communicated.”

Engage with your community

Companies can show their support by partnering with organizations or events that support marginalized groups. Asana has sponsored and spoken at the Out For Undergrad Technology conference for three years, and recently sponsored and spoke at Lesbians Who Tech.

Bring your authentic self to work

We encourage all Asanas to bring their authentic selves to work. Patrick, from sales, notes that, “It’s weird, I don’t feel like I have to try to bring my full self to work, which I used to think about more before working in tech—now I don’t have to psych myself up just to be myself each day [laughs].” To help people feel like they can be themselves, we “affirm that we really do mean the sincere-sounding things that we say—like, can you really have managers who are responsible for emotional and career growth? Yes, you can,” says Rachel. Finally, even something as simple as a flexible dress code can matter. Josh notes, “I appreciate that so many other people use clothing as an avenue to express themselves and it’s something that I’ve been able to do here. I can have fun with clothing and my personal expression of how I want to be seen at work and not have it fit into rigid fashion format or corporate dress code.”

Encourage employees to bring their authentic selves to work. #organizedwithprideTweet

All of this said, Patrick reminds us that “there’s a flipside to having been in an inclusive environment for so long, which is making sure you respect people’s journey to bringing their full selves to work. If they don’t want to or aren’t ready, they shouldn’t be pushed in that direction.”

The LGBTQIA community and tech On change

There have been many changes in the LGBTQIA community in the past few years. To Patrick, “The tech community has been at the forefront of changes that we’re now seeing across wider corporate America around how employees in the community are treated in the workplace,” and we’re starting to finally see changes outside of tech.

On support

We have also seen a lot of support programs showing up in tech, like mentorship and Employee Resource Groups (ERGs). Tim has noticed “a shift from focusing on ourselves at work to thinking about those who are coming into tech or need more support.” There also are more and more spaces for people to meet in, whether they’re happy hours , conferences, or meetups.

On success

For Josh, seeing examples of success “like Tim Cook becoming CEO of Apple and other examples of people being their full selves” has been inspiring.

The work’s not done.

There are many ways to get involved in LGBTQIA allyship in both the workplace and your community, including speaking at events, talking to candidates about diversity, asking about gender pronouns – or even just providing open channels for communication and flagging issues. Rachel feels “most seen by [her] company when others notice the issues that [she’d] otherwise have to be the one speaking up about.” There’s always room for improvement, too — and the work is far from done. But when “a company can acknowledge its shortcomings and do work without it only being driven by the marginalized employee group—that’s cool.”

Categories: Companies

What We’re Reading This Week: A Peak Into Creative Genius, Productivity and More

The LiquidPlanner Blog - Fri, 06/24/2016 - 17:27
What we're reading


What we

Every week we bring you the best of what we’re reading from around the web. This week’s stories center on speed, efficiency, working well with others and there’s an intriguing piece on how a Harvard Business School professor studied Pixar’s formula to rethink leadership and innovation. I hope these posts bring you a bit of joy and insight into getting the most out of your day. Happy reading!

This Professor Teaches Pixar’s Approach to Creative Genius –

How to Double Your Writing Speed –  Huffington Post 

It’s Time to Stop Trying to Do It All –

4 Soft Skills You Need to Work on, and Why –

Why Managers and Staff Have Very Different Ideas About Open Offices– Fast Company

7 Time-Saving Ways to Automate Your Everyday Tasks – Fast Company


Bonus Story! Our most read blog post of the week:

How to Motivate Your Team to Track Time 

Like what you read? Have suggestions? Drop me a note @mmerwin.

For skillful insight on how to be the top dog of project managers, download our handbook, “The Ultimate Project Management Guide.”

Ultimate PM Guide


The post What We’re Reading This Week: A Peak Into Creative Genius, Productivity and More appeared first on LiquidPlanner.

Categories: Companies

Virtual Leadership: Interview With Author Penny Pullan

In this video I interview author Penny Pullan about her new book, Virtual Leadership: Practical Strategies for Getting the Best Out of Virtual Work and Virtual Teams, which is out this year. We filmed this video in an apartment in Barcelona where we were staying during the PMI Global Congress. It was Penny’s idea to have wine in the film (although I didn’t argue). I have edited out most of the giggling!

Penny has kindly organised you a discount.

Go to the publisher’s website and use the coupon FRIENDSOFPENNY for 20% off.

This article contains affiliate links.

You'll also like:

  1. Penny Pullan talks about writing A Short Guide to Facilitating Risk Management In this video I talk to Penny Pullan, co-author of A Short Guide to Facilitating Risk Management. If you prefer to read a transcript, that...
  2. Leading Effective Virtual Teams [Book Review] Leading Effective Virtual Teams is one of the harder books I have had to review, but one of the easiest to read. It's very practical,...
  3. Project Management Answers: Interview with author Jeff Furman The PMBOK® Guide v5 refresh introduced new topics for students taking the PMP exam. Jeff Furman, author of The Project Management Answer Book, has just...
  4. 5 Tips for Virtual Meetings [Video] Watch this video to find out the 5 things you can do to make your virtual team meetings more interesting and more productive for everyone....
  5. 4 Easy Tips For Effective Virtual Meetings Virtual meetings are a fact of life. These 4 easy tips take only moments to put into practice but will hugely improve the quality of...

Categories: Blogs

Meet the 2016 SEP Interns

SEP Project Management Blog - Thu, 06/23/2016 - 22:32

jessicaJessica Vaughn

Software Engineering Intern

School: IUPUI

Major: Informatics

Project: Web-based Management System for Construction Equipment

“I chose SEP because of the opportunities as well as the culture. SEP cares about its employees and wants them to grow and learn and feel comfortable. There are also a variety of projects, which means lots of different technologies and programming languages that teams can work with.”


calebCaleb Tung

Software Engineering Intern

School: Purdue

Major: Computer Engineering

Project: Product Pricing Analysis Software Application

“I picked SEP because one summer here could teach me so much. At SEP, I knew I’d be surrounded by really smart engineers and I was looking forward to picking their brains and learning about the software development process. Most importantly, I knew my work would be relevant and exciting. Oh, and the office is really, really cool.”


joeJoe Coy

Software Engineering Intern

School: Purdue

Major: Computer Science

Project: FORUM Mobile Banking App

“I chose to return to SEP for my 5th internship with the company because they have a great atmosphere where people are open to helping others, questions are encouraged, and learning is a priority. I find that every year I’m at SEP, they offer new experiences and learning opportunities due to the variety of projects and team members.  I enjoy and grow from every internship that I spend here.”


rebeccaRebecca Keys

Business Intern

School: Purdue

Major: Industrial Engineering

Project: User Research Methods & Recruitment Marketing

“I chose SEP because I knew an internship here would mean the opportunity to do meaningful work on real projects. Everyone at SEP is so eager to learn, curious, and passionate about the work they do. These things really drew me to SEP as a company, along with the incredible culture they have.”


katrinaKatrina Kerrick

Software Engineering Intern

School: Rose-Hulman

Major: Computer Science

Project: Virtual Collaboration Software

“I knew that I wanted to work for SEP when I went to one of their info sessions at Rose-Hulman.  I liked everything I saw during their presentation, and I visited them at the career fair and liked what I saw even more. I’m so glad I attended their session, because I ended up working at this awesome company!”


jackJack McClary

Software Engineering Intern

School: Rose-Hulman

Major: Computer Science/Math

Project: Software for a Medical Device Manufacturer

“I chose SEP for my internship because it offered so many additional opportunities outside of work. The startup weekend was one thing that drew me in. The fact that SEP was dedicated and committed to letting their employees be creative was a big factor in my decision. I liked that SEPLabs supported new ideas and innovation internally.”


elliotElliot Yesmunt

Software Engineering Intern

School: IUPUI

Major: Computer Science

Project: Embedded Display System for Agricultural Machinery

“From the research I did on SEP before I interviewed, everyone at SEP seemed to really like the variety of the projects they worked on. Some said it was almost like having a different job every 5 years. This freshness was definitely appealing to me.”


jeremyJeremy Wright

Software Engineering Intern

School: Rose-Hulman

Major: Computer Science

Project: Embedded Display System for Agricultural Machinery

“I chose SEP because I saw them at the career fair and heard they were from Carmel, which is where I’m from. I read about them online, asked both the employees and other students about the company, and became more interested in interning with them over time. SEP was also at a few hackathons I attended, and I met employees who helped me get a better understanding of SEP’s culture. A few interviews and a couple emails later and now I’m here!”

Categories: Companies

Summer of Agile Reading List

Tasktop Blog - Thu, 06/23/2016 - 17:44

This week marked the official start of summer in the northern hemisphere, and here at Tasktop, we’ve declared this the Summer of Agile. We got started a bit early with last week’s webinar: SAFe & Requirements Management: Oxymoron or Practical Reality? with our VP of Product Management, Nicole Bryan. To be fair, Nicole and I are based in Austin, Texas where summer has been in full swing for a while. Next month, we’ll be joined by Dave West from for the second part of our series: Beyond the Scrum Team: Delivering “Done” at Scale.

But, the Summer of Agile isn’t all about webinars. For one, we’re putting together a summer reading list to help everyone brush up on their Agile skills. We’d love to hear what you think should be included, and have gathered a few recommendations from the Tasktop team to get things started. We’re looking for a variety of titles ranging from introductions to the methodology to deeper discussions for more experienced practitioners.

To start us off, we have a couple of titles plucked right off the bookshelf of Tasktop CEO Mik Kersten:
Agile!: The Good, the Hype and the Ugly by Bertrand Meyer
Agile Project Management with Scrum by Ken Schwaber
Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation by Jez Humble & David Farley

Scrum: The Art of Doing Twice the Work in Half the Time
by Jeff Sutherland & J.J. Sutherland
This book Scrumwas a great intro to Scrum from one of the framework’s co-creators. As a non-engineer in a tech company, I particularly enjoyed the stories about how Scrum has been applied outside of software development, and found the discussion of the perils of multi-tasking and the importance of the doing the job right the first time to be widely applicable.
Recommended by: Sarah Ryan, Marketing Operations Manager (Yeah, that’s me.)

Kanban: Successful Evolutionary Change for Your Technology Business
by David J Anderson
Excellent inKanbantroduction and in-depth look at implementing a kanban system for software delivery. Also very useful for practical implementation of kanban, and being able to grow a kanban system within a system of other constraints.  The author is an authority on the subject.
Recommended by: Ryan Golbeck, Senior Software Engineer

Agile Testing: A Practical Guide for Testers and Agile Teams
by Lisa Crispin & Janet Gregory
One of the biggest mistakeAgile Testings that organizations make when adopting Agile practices is ignoring how testing fits in. Sadly, it’s all too typical among waterfall teams that testing is relegated to a phase that happens after the coders are done. If “moving to Agile” simply means that coders now operate in 2-4 week sprints, then testing gets squeezed even further. This book is a practical introduction of how to avoid this horrible circumstance.
Recommended by: Betty Zakheim, VP of Industry Strategy

As much as we love reading about Agile, sometimes you really want to sit back and watch stick figures explain concepts to you. That’s why we decided to open up our reading list to all media.

Agile Project Ownership in a Nutshell by Henrik Kniberg
This is a great intro video. It was introduced to a few of us during our CSM training and has made the rounds internally a few times. The focus is on the PO, but it gives a good overview of the whole framework.
Recommended by: Clint Morgan, Software Engineer

So…what about you? Comment to let us know which books, videos, blogs, or other media have helped you learn and improve your Agile practice.

Categories: Companies

Product Owners and Learning, Part 3

Part 1 was about how the PO needs to see the big picture and develop the ranked backlog. Part 2 was about the learning that arises from small stories. This part is about ranking.

If you specify deliverables in your big picture and small picture roadmaps, you have already done a gross form of ranking. You have already made the big decisions: which feature/parts of features do you want when? You made those decisions based on value to someone.

I see many POs try to use estimation as their only input into ranking stories. How long will something take to complete? If you have a team who can estimate well, that might be helpful. It’s also helpful to see some quick wins if you can. See my most recent series of posts on Estimation for more discussion on ranking by estimation.

Estimation talks about cost. What about value? In agile, we want to work (and deliver) the most valuable work first.

Once you start to think about value, you might even think about value to all your different somebodies. (Jerry Weinberg said, “Quality is value to someone.”)  Now, you can start considering defects, technical debt, and features.

The PO must rank all three possibilities for a team: features, defects, and technical debt. If you are a PO who has feature-itis, you don’t serve the team, the customer, or the product. Difficult as it is, you have to think about all three to be an effective PO.

The features move the product forward on its roadmap. The defects prevent customers from being happy and prevent movement forward on the roadmap. Technical debt prevents easy releasing and might affect the ease of the team to deliver. Your customers might not see technical debt. They will feel the effects of technical debt in the form of longer release times.

Long ago, I suggested that a specific client consider three backlogs to store the work and then use pair-wise comparison with each item at the top of each queue. (They stored their product backlog, defects, and technical debt in an electronic tool. It was difficult to see all of the possible work.) That way, they could see the work they needed to do (and not forget), and they could look at the value of doing each chunk of work. I’m not suggesting keeping three backlogs is a good idea in all cases. They needed to see—to make visible—all the possible work. Then, they could assess the value of each chunk of work.

You have many ways to see value. You might look at what causes delays in your organization:

  • Technical debt in the form of test automation debt. (Insufficient test automation makes frictionless releasing impossible. Insufficient unit test automation makes experiments and spikes impossible or quite long.)
  • Experts who are here, there, and everywhere, providing expertise to all teams. You often have to wait for those experts to arrive to your team.
  • Who is waiting for this? Do you have a Very Important Customer waiting for a fix or a feature?

You might see value in features for immediate revenue. I have worked in organizations where, if we released some specific feature, we could gain revenue right away. You might look at waste (one way to consider defects and technical debt).

Especially in programs, I see the need for the PO to say, “I need these three stories from this feature set and two stories from that other feature set.” The more the PO can decompose feature sets into small stories, the more flexibility they have for ranking each story on its own.

Here are questions to ask:

  • What is most valuable for our customers, for us to do now?
  • What is most valuable for our team, for us to do now?
  • What is most valuable for the organization, for us to do now?
  • What is most valuable for my learning, as a PO, to decide what to do next?

You might need to rearrange those questions for your context. The more your PO works by value, the more progress the team will make.

The next post will be about when the PO realizes he/she needs to change stories.

If you want to learn how to deliver what your customers want using agile and lean, join me in the next Product Owner workshop.

Categories: Blogs

Building a Delightful FORUM App

SEP Project Management Blog - Wed, 06/22/2016 - 22:08

In the past few months, SEP has continued working in partnership with FORUM Credit Union (FCU) to develop the latest update of the FORUM iOS app. In order to create an effective, delightful app, SEP’s FORUM team conducted research within the company to better understand how SEPeers interact with FCU and its app. To begin this research, the team released a survey within SEP.
In the survey, participants were asked about…

  1. general use of the FORUM app and other banking apps
  2. satisfaction with the FORUM app
  3. interest in providing feedback to our FORUM iOS team

Additionally, survey participants had the option to choose from a handful of methods to provide in-person feedback to our FORUM team. Depending on their preferences, they could choose to provide feedback by participating in a discussion, sharing their design ideas, or even trying out a prototype of the app.
The first round provided 19 survey responses, and uncovered vital information that will help our FORUM team build the right thing. According to the results, 50% of the survey participants use the FORUM iPhone app. Additionally, the results revealed that the most frequently used feature of the iOS app is the account summary feature, closely followed by the transaction list. More general feedback discovered from our first round of the survey is in the infographic below:

With the first round of responses, our FORUM team was able to perform semi-formal user testing with a handful of SEPeers. For this research study, the team sat down with participants and asked them a few questions as they navigated the prototype of the app. Our FORUM team learned that many users had trouble understanding the icons depicting a check or a memo, and was able to adjust our design accordingly. With the research the team conducted, they were able to gain a better understanding of the FORUM app from the standpoint of the user and design an update better suited for the user’s needs.user_research

Looking forward, the team has released another round of surveys within SEP, and is anticipating more feedback from SEPeers, along with more user research. We are so excited to be working together with FORUM to create a great mobile banking experience!

Categories: Companies

My Improved Travel Checklist

NOOP.NL - Jurgen Appelo - Wed, 06/22/2016 - 17:20
My Improved Travel Checklist

Last week in London, I wanted to shoot a video, but it appeared that I had left my camera’s memory cards at home. On my previous trip, it had been my Android tablet that I had forgotten to bring with me. The trip before that, it was my stack of local currency, my power adapters, my sunglasses, or whatever, which I hadn’t properly packed.

Sure, I have a travel checklist. But clearly, it had turned into a checklost. With at least 50 confirmed upcoming events around the world, it was time for me to redesign it.

Four Preferred Places

My original checklist was one large unorganized list of reminders. This regularly led to problems because, by scanning the list too quickly, I easily overlooked an item that was buried among all the other things that I only knew too well. So I divided the checklist into four parts:

  • Personal items (that I carry on my body)
  • Shoulder bag
  • Handbag (typically carry on luggage)
  • Extra bag (typically check in luggage)

Each travel item on my improved checklist now has a preferred place. This not only helps to keep the individual lists smaller, and easier to check more carefully, but it also helps me keep things in the right bag. I don’t want to have that situation again where I thought I had my universal adapters or chargers packed in the other bag (but found out later that I hadn’t).

(And preferred means that items can change places depending on context. For example, my keys will have moved to my shoulder bag before I arrive at the airport, while my passport may temporarily move to my pocket while suffering the security and customs rituals.)

Standard versus Extra

Another thing I noticed messing up my packing efforts was that some standard items are by default in my bags (such as passports and adapters), other extra things are by default out of my bags (such as clothes and toiletries), and some items had a Schrödinger-kind of existence, not clearly being in or out, until I opened my bags to have a look (such as device chargers and headphones).

After the reorganization, packing my bags with my improved checklist now consists of two distinct activities:

  1. Checking that all standard items are where they should be;
  2. Adding all extra items to the place where I want them.

Hopefully, this will save me some stress and headaches in the future.

For example, I once had to interrupt my trip to the airport because my passport was not in my bag: it was still under the scanner next to my computer. I always know that my passports are in my shoulder bag, except for the one or two times when, apparently, I was wrong. And thus, I made it a separate activity to check that I am not deceiving myself, thinking that the standard items are where they should be before adding all extra items. And a Schrödinger-kind of existence is not part of the improved design.

Optional Stuff

And then, of course, there are the optional items that mainly depend on the weather forecasts. I remember once nearly freezing to death in Helsinki because I had no warm coat or gloves. I was once drying my clothes in my hotel room in London because, stupidly, I had brought no umbrella. And more than once, I have been sweating in the sun because I was silly enough to bring only dark blue jeans and long-sleeve shirts.

Short versus Long trips

Finally, things can always change a bit depending on context.

On short trips (one or two nights), I don’t need to take the larger bag with me. But this means I must jam any books, running gear, and clean clothes into my hand luggage, which is not always possible, or else just leave some of it at home. And on long trips (ten or more nights), the large bag magically changes into an extra large suitcase, and this also changes what I can bring with me (usually a lot more clothes).

Well, there you have it: the philosophy behind my new-and-improved travel checklist. I include the full list below (as it is now).

Is there anything missing that you have on your travel checklist, and that may be useful for me as well?

House keys
Car keys

Shoulder bag – standard items
Credit cards and bank cards
Travel cards and loyalty cards
Pens and markers
Presentation clicker
Spare batteries
Memory sticks
Display adapter

Shoulder bag – extra items
Tablet + charger
Foreign currency

Handbag – standard items
Spare underwear, socks, and shirt
Spare medicine, contact lenses
GoPro camera
GoPro stick
GoPro batteries
GoPro charger
GoPro memory
GoPro microphone
Universal adapters
USB chargers
Business cards

Handbag – extra items
Notebook + charger
Gloves, scarf, ear muffs [IF forecast = cold]
Umbrella [IF forecast = wet]
Travel clothes [IF distance = long]

Large bag – standard items
Laundry bag

Large bag – extra items
Extra shoes
Running shoes and clothes
Book / giveaway
Fleece jacket [IF forecast = cold]
Warm socks and sweater [IF forecast = cold]
Raincoat [IF forecast = wet]
Short pants [IF forecast = hot]

photo (c) 2013 Chris Lott, Creative Commons 2.0

My new book Managing for Happiness is available from June 2016. PRE-ORDER NOW!

Managing for Happiness cover (front)

The post My Improved Travel Checklist appeared first on NOOP.NL.

Categories: Blogs

Product Owners and Learning, Part 1

When I work with clients, they often have a “problem” with product ownership. The product owners want tons of features, don’t want to address technical debt, and can’t quite believe how long features will take.  Oh, and the POs want to change things as soon as they see them.

I don’t see this as problems.To me, this is all about learning. The team learns about a feature as they develop it. The PO learns about the feature once the PO sees it. The team and the PO can learn about the implications of this feature as they proceed. To me, this is a significant value of what agile brings to the organization. (I’ll talk about technical debt a little later.)

AgileRoadmap.copyright-1080x794One of the problems I see is that the PO sees the big picture. Often, the Very Big Picture. The roadmap here is a 6-quarter roadmap. I see roadmaps this big more often in programs, but if you have frequent customer releases, you might have it for a project, also.

I like knowing where the product is headed. I like knowing when we think we might want releases. (Unless you can do continuous delivery. Most of my clients are not there. They might not ever get there, either. Different post.)

Here’s the problem with the big picture. No team can deliver according to the big picture. It’s too big. Teams need the roadmap (which I liken to a wish list) and they need a ranked backlog of small stories they can work on now.

Example.AgileRoadmapOneQuarter In Agile and Lean Program Management, I have this picture of what an example roadmap might look like.

This particular roadmap works in iteration-based agile. It works in flow-based agile, too. I don’t care what a team uses to deliver value. I care that a team delivers value often. This image uses the idea that a team will release internally at least once a month. I like more often if you can manage it.

Releasing often (internally or externally) is a function of small stories and the ability to move finished work through your release system. For now, let’s imagine you have a frictionless release system. (Let me know if you want a blog post about how to create a frictionless release system. I keep thinking people know what they need to do, but maybe it’s as clear as mud to  you.)

The smaller the story, the easier it is for the team to deliver. Smaller stories also make it easier for the PO to adapt. Small stories allow discovery along with delivery (yes, that’s a link to Ellen Gottesdiener’s book). And, many POs have trouble writing small stories.

That’s because the PO is thinking in terms of feature sets, not features. I gave an example for secure login in How to Use Continuous Planning. It’s not wrong to think in feature sets. Feature sets help us create the big picture roadmap. And, the feature set is insufficient for the frequent planning and delivery we want in agile.

I see these problems in creating feature sets:

  • Recognizing the different stories in the feature set (making the stories small enough)
  • Ranking the stories to know which one to do first, second, third, etc.
  • What to do when the PO realizes the story or ranking needs to change.

I’ll address these issues in the next posts.

If you want to learn how to deliver what your customers want using agile and lean, join me in the next Product Owner workshop.

Categories: Blogs

Product Owners and Learning, Part 2

In Part 1, I talked about the way POs think about the big picture and the ranked backlog. The way to get from the big picture to the ranked backlog is via deliverables in the form of small (user) stories. See the wikipedia page about user stories. Notice that they are a promise for a conversation.

I talked about feature sets in the first post, so let me explain that here. A feature set is several related stories. (You might think of a feature set as a theme or an epic.) Since I like stories the team can complete in one day or less, I like those stories to be small, say one day or less. I have found that the smaller the story, the more feedback the team gets earlier from the product owner. The more often the PO sees the feature set evolving, the better the PO can refine the future stories. The more often the feedback, the easier it is for everyone to change:

  • The team can change how they implement, or what the feature looks like.
  • The PO can change the rest of the backlog or the rank order of the features.

I realize that if you commit to an entire feature set or a good chunk for an iteration, you might not want to change what you do in this iteration. If you have an evolving feature set, where the PO needs to see some part before the rest, I recommend you use flow-based agile (kanban). A kanban with WIP limits will allow you to change more often. (Let me know if that part was unclear.)

Now, not everyone shares my love of one-day stories. I have a client whose team regularly takes stories of size 20 or something like that. The key is that the entire team swarms on the story and they finish the story in two days, maybe three. When I asked him for more information, he explained this it in this way.

“Yes, we have feature sets. And, our PO just can’t see partial finishing. Well, he can see it, but he can’t use it. Since he can’t use it, he doesn’t want to see anything until it’s all done.”

I asked him if he ever had problems where they had to redo the entire feature. He smiled and said,

“Yes. Just last week we had this problem. Since I’m the coach, I explained to the PO that the team had effectively lost those three days when they did the “entire” feature instead of just a couple of stories. The PO looked at me and said, “Well, I didn’t lose that time. I got to learn along with the team. My learning was about flow and what I really wanted. It wasn’t a waste of time for me.”

“I learned then about the different rates of learning. The team and the PO might learn differently. Wow, that was a big thing for me. I decided to ask the PO if he wanted me to help him learn faster. He said yes, and we’ve been doing that. I’m not sure I’ll ever get him to define more feature sets or smaller stories, but that’s not my goal. My goal is to help him learn faster.”

Remember that PO is learning along with the developers and testers. This is why having conversations about stories works. As the PO explains the story, the team learns. In my experience, the PO also learns. It’s also why paper prototypes work well. Instead of someone (PO or BA or anyone) developing the flow, when the team develops the flow in paper with the PO/BA, everyone learns together.

Small stories and conversations help the entire team learn together.

Small features are about learning faster. If you, too, have the problem where the team is learning at a different rate than the PO, ask yourself these questions:

  • What kind of acceptance criteria do we have for our stories?
  • Do those acceptance criteria make sense for the big feature (feature set) in addition to the story?
  • If we have a large story, what can we do to show progress and get feedback earlier?
  • How are we specifying stories? Are we using specific users and having conversations about the story?

I’ve written about how to make small stories in these posts:

The smaller the story, the more likely everyone will learn from the team finishing it.

I’ll address ranking in the next post.

If you want to learn how to deliver what your customers want using agile and lean, join me in the next Product Owner workshop.

Categories: Blogs

5 Steps to a Successful Rollout of LiquidPlanner

The LiquidPlanner Blog - Wed, 06/22/2016 - 16:59
LiquidPlanner RolloutLiquidPlanner Rollout

As a Customer Success guru, I’ve seen some exceptional implementations of LiquidPlanner over the past six years. I’ve also seen my fair share of not–so-great rollouts. And, it is safe to say that I’ve certainly noticed a few clear trends along the way!

There is no getting around it: The approach you take in your rollout is directly tied to whether your team will adopt LiquidPlanner in the long-term or eventually toss it by the wayside. How you plan, who leads the implementation, and how you communicate the why and how LiquidPlanner will be used are vital to success. It’s worth getting these right the first time around.

Sharing recommended practices to help our customers be successful is one of my favorite parts of the job. So here it is—my learnings on the key factors linked to not only a smooth rollout, but also long-term adoption of LiquidPlanner:

1. Identify a Champion

You need a Champion, really! This is the person responsible for rolling LiquidPlanner out to the team. They don’t have to carry pompoms, but they do have to put on their Project Manager hat and treat your rollout like you would a project. As you’re sweeping your team for a potential Champion, you’ll want to look for someone who can be both the subject matter expert and internal POC (Point of Contact) for all things related to your workspace – they should have a knack for helping users learn and get comfortable in the application during the initial rollout phase and beyond.

If you are running a large scale or complex implementation, one Champion won’t be enough. Consider having a designated group to manage your rollout to ensure one person isn’t left with the lion’s share of the work. If not a group, you’ll find that having at least a co-champion can be a saving grace.

In general, having a back-up POC for LiquidPlanner is a great practice – as it ensures that things won’t array when your Champion is beachside on vacation!

2. Get executive sponsorship

You can have a rock star Champion, but they can only do so much without support from upper management. Fully embracing a new tool requires buy-in from the entire team – everyone has to understand why LiquidPlanner was selected and the value it will bring in order to get through the change process it requires. And, your Executive Champion can provide the needed messaging to get everyone on board.

Executive-level involvement alone will convey that using LiquidPlanner is not a suggestion, but essential. This provides the roots for long term adoption.

3. Make the LP Playbook the core of your implementation

In order to drive consistent usage and get reliable data, your team needs to use LiquidPlanner in the same way. Several key questions must be answered:

  • Who manages incoming work and how is it triaged?
  • How frequently must project contributors track time?
  • Who sets priorities in the workspace?
  • Who is responsible for setting the original estimates of work?

Once you’ve addressed these questions, the business rules and workflows that have surfaced should be documented in a guide. We call this guide the LP Playbook and provide you a template to make your own!  The best results I’ve seen are when the Champion partners with key stakeholders to define how users need to engage in the workspace, and your Executive Champion then promotes the LP Playbook.

It is important that this document communicates why your team will use LiquidPlanner; stating your goals and how this PM tool will help you achieve your department or company initiatives. When project contributors have a clear guide to reference it reduces uncertainty and any hesitation or fear of working in LiquidPlanner. The result: faster (and more!) engagement.

When thinking about your business rules, make sure that they support your goals in using LiquidPlanner. For example, if your objective is to better understand where your team is spending their time, tracking time daily would be a key business rule for you.

4. Architect a sound workspace structure, then hold a Kickoff meeting

The way you build out your package structure, project work breakdowns, and custom elements like activities and custom fields must align with your workflows and business requirements. Once your LP Playbook is complete and the workspace is ready, it’s time to invite in project contributors and formally introduce LiquidPlanner to the team.

Some of the most successful introductions I’ve seen involve a formal LiquidPlanner Kickoff hosted by the Champion and Executive Champion, where the team is gathered to walk through your workspace setup and LP Playbook. And, when excitement and buzz is still fresh, distribute your LP Playbook to the team for reference moving forward—mandating the crystal clear expectations you’ve outlined for them.

5. Carve out time for your rollout and don’t lose momentum

You’ve all heard this before, but I have to say it again just for good measure:

Rolling out any new technology takes time and careful consideration. And while LiquidPlanner has a scheduling algorithm that is practically magic, it doesn’t have the power to get buy-in from your team, hand them their LP Playbook, or architect your workspace for you. The reality is that time needs to be reserved to do these things and to do them right.

This is where your Executive Champion comes in to play—again! They should ensure that your Champion has time in their day to dedicate to LiquidPlanner and to remain focused on the implementation over time. The last thing you want is to spend effort getting the rollout going only to put LiquidPlanner on the backburner due to higher-priority issues. You’ll want to keep a sense of urgency until your team is fully up and running in the workspace. If you lose momentum, your rollout will take a hit and this can negatively impact long-term adoption.

Remember, the way you implement LiquidPlanner can make or break long-term success. Having the right champions on board (who have time and aren’t overloaded!), developing clear and positive communication around usage, and architecting a supportive workspace structure cultivates the roots needed for the consistent adoption that ensures you’ll achieve your business goals. If you’re thorough and patient with your rollout process, your team will be up and running smoothly before you know it.

See Preparing for Liftoff for more on rolling out LiquidPlanner to your team.

 If you want to learn more about onboarding and motivating your team to use your new project management tool, and how to approach other classic project management speed bumps, download our eBook:  How to Solve the Top 9 Project Management Challenges.”

Solve the Top 9 PM Challenges

The post 5 Steps to a Successful Rollout of LiquidPlanner appeared first on LiquidPlanner.

Categories: Companies

New End of Release Demo Process

Tasktop Blog - Wed, 06/22/2016 - 16:34

End of Release Blog Image
At Tasktop, we pride ourselves on not missing releases. We have not missed a release in over four years. And we release quarterly. That’s a pretty good record. As part of our releases, we hold internal release demos where the teams get to show off the new features they’ve added to the product. And we hold this end of release demo every 3 months without fail. There’s only one problem with the end of release demo…

It’s as boring as watching paint dry.

I cringe to say that because we have some whip-smart developers who can work miracles. But it’s true. Our end of release demos were rough. Part of it is how our product is built. We help companies solve business problems by providing integrations between their software development tools. We build connectors to a variety of ALM, PPM and QA tools and we build the integration engine that serves as the hub for these connectors. A large part of our demos were structured around supporting new artifacts (stories, defect, requirements, etc) or fields (text fields, single-select fields, multi-select fields, etc). After a few years of showing one field synchronized to another field, it gets a bit predictable.

In some ways, we’re a victim of our own success. When customers first see what we can do, they’re amazed, but we see behind the curtain and know how the sausage is made. I don’t need to see another single select field mapped to a string field. If you’ve seen this for one tool, it’s not a stretch to understand that it can be done with another tool.

Even engineering became bored with our demos. When the people showing off the new stuff get bored with how they’re showing it off, you know something has to be done.

So six months ago, we hatched a plan.


We decided to create one unified demo that shows how our new features solve an actual customer need. Instead of five development teams each presenting their own stand-alone demos that had nothing to do with each other, we would now have one unified demo across the entire engineering team. The Product team would be in charge of developing a demo story that could be told using the features developed in this release. Not all the team members would demo. And more importantly, not all the new features would be demo’d in the end of release demo. Some features may be too small or may not fit the demo scenario. Besides, we already record all the Sprint demos, so if you really need to see something in action, check out the team’s sprint demo.

What Happened

People loved it.

We’ve only gone through this twice, but it’s going great. The response from engineering as well as our other internal stakeholders was immediate and clear. We had glowing emails coming in within minutes of our first go with this new demo process.

Instead of the demo being a lot of disconnected standalone features, it became one comprehensive story. It also became much faster. Instead of taking the traditional 2.5 hours, we slimmed it to under an hour.

Most importantly it demonstrated to everyone that we make ONE SOLUTION that solves serious problems. We may have multiple products with various features, but at the end of the day, they are used together to help businesses deliver better software faster. Creating a demo story that explains to our stakeholders what customer problems we can solve today is incredibly powerful.

What’s Next
We have a few additional action items:

  1. Be more specific in pointing out the new stuff.
    Now that demos are a holistic story, they incorporate both existing and new features. We need to do a better job of pointing out in the demo “this is new functionality”.
  1. Start the process earlier.
    We can craft our demo story almost as soon as we finish our release plans. That gives the teams almost three months to prepare. That way, engineering will know from the very start of the release, what features will be presented at the end of the release.
  1. Shorten the scheduled time for the demo.
    After this most recent demo ended, the entire engineering organization looked around like, “what do we do now?” There was over an hour still on the schedule for demos. That was a holdover from our old process. We can now schedule other events and simply give people their time back.

It’s not every day you can give your organization over a person-week of time back, but we did it with this new demo process. Tasktop’s mission is to help companies deliver software better and faster, it only makes sense that we continue to strive to improve our own processes.

Categories: Companies

Be Careful Which Projects You Agree to Manage

Project Management Articles - PM Hut - Wed, 06/22/2016 - 16:01
Be Careful Which Projects You Agree to Manage By James Young I am bewildered when I encounter organizations wherein projects are created or bids won and then assigned to a Project Manager who has no prior knowledge of the project. Why would a Project Manager accept the responsibility for a project that he/she did not participate in [...]
Categories: Communities

Clarifying Misconceptions of the Big Launch

Extract from Science of Growth

Do you think that your project should have a ‘launch’ event? In this extract from The Science of Growth*, Sean Ammirati shows that a single, formal big launch isn’t always what kickstarts a company (or a project) into the big league. What really works might surprise you – it’s definitely something to work on when you are thinking about positive project risk! Enjoy…

A founder’s core vision, in hindsight, will typically look obvious. However, at the time the founders embark on their journey their vision is often a truth that many others don’t yet realize. It’s therefore tempting to think that the key to success is to find a big enough stage or platform on which to unveil your solution. However, as students of the lean entrepreneurship movement hear repeatedly, it’s usually not a good idea to launch your product with a “big bang.” This is solid counsel from my experience.

Although this is solid counsel on day one of a startup, it may not be such sage advice later on. One thing we repeatedly noticed in our study, across many of our chosen companies, was that some successful startups built awareness by drafting off larger events to catalyze growth once they had completed the four prerequisites described in section one.

Later, many of these events seem to be considered the startup’s “launch,” advancing the misconception that a big bang launch is a prerequisite for success. In none of the companies we analyzed is this more apparent than Twitter.

I’ve been attending the South by Southwest (SxSW) conferences since before Twitter’s breakout year in 2007. And every year since 2007, journalists rush home to talk about the next thing to launch at SxSW, and ask whether [insert startup name here] is the next Twitter. It’s a great narrative for these journalists, especially when you consider Twitter is today worth over $21 billion. This story of SxSW launching Twitter has dramatically increased the popularity of the SxSW Interactive Festival and become startup folklore.

Unfortunately, it’s not actually true that Twitter was launched at SxSW. As described by Evan Williams on Quora, here is what actually happened (emphasis mine):

. . . contrary to common belief, we didn’t actually launch Twitter at SXSW—SXSW just chose to blow it up. We launched it nine months before—to a whimper. By the time SXSW 2007 rolled around, we were starting to grow finally and it seemed like all of our users (which were probably in the thousands) were going to Austin that year. So, we did two things to take advantage of the emerging critical mass:

  1. We created a Twitter visualizer and negotiated with the festival to put flat panel screens in the hallways. This is something they’d never done before, but we didn’t want a booth on the trade show floor, because we knew hallways is where the action was. We paid $11K for this and set up the TVs ourselves. (This was about the only money Twitter’s *ever* spent on marketing.)
  2. We created an event-specific feature, where, you could text “join sxsw” to 40404. Then you would show up on the screens. And, if you weren’t already a Twitter user, you’d automatically be following a half-dozen or so “ambassadors,” who were Twitter users also at SXSW. We advertised this on the screens in the hallways. (I don’t know how many people signed up this way—my recollection is not a lot.)

I don’t know what was the most important factor, but networks are all about critical mass, so doubling down on the momentum seemed like a good idea. And something clicked.

When we look through the cases we’ve analyzed, this pattern of a product or service launching and then later having a big event “to blow it up” appears to be common. As we started looking at these later events, we started calling them a “double trigger”—the first trigger was getting the product in the market and getting feedback, but this second event was the double trigger that ultimately catalyzed growth. I’d like to highlight three types of events that can have this catalyzing impact.

Double Trigger Type 1: Something Happens to Your Product

In December 2005, Saturday Night Live aired a digital short called “Lazy Sunday” starring Andy Samberg and Chris Parnell. The video was a hit on SNL and was uploaded to YouTube shortly after it aired. While eventually the video was pulled at NBC Universal’s request (for copyright reasons), this didn’t happen until February, after over seven million views of the video on YouTube’s service. When website analytic vendors like HitWise plot the growth of YouTube’s traffic, you can easily see the day in December 2005 when “Lazy Sunday” started accelerating growth dramatically. That increase in growth wasn’t short lived, but in fact continued from that point forward.

Based on that impact, Rick Cotton, chief counsel of NBC Universal, argued at an industry event that NBC ultimately made YouTube worth $1.5 billion. While that seems a bit extreme, the popularity of “Lazy Sunday” certainly catalyzed YouTube’s growth. As a reminder, at the point Rick Cotton made the claim, Google had recently acquired YouTube for $1.5 billion.

Double Trigger Type 2: A Big Event Needs Your Product

In 2008, the Democratic Party made the decision to move Obama’s speech at their convention in Denver from the Pepsi Center (capacity 18,007) to the larger outdoor venue of Invesco Field (capacity 76,125). The decision immediately created logistical challenges, as there simply were not enough hotels in Denver to handle the expected additional visitors, but it created a catalyst for Airbnb.

Later CNN Money reported on that accommodation crisis moment:

For Airbnb co-founder Brian Chesky, that was a Eureka moment.

“We were thinking to ourselves . . . light bulb’s going off,” he said. “That’s where they’re going [to] stay: They’re going [to] stay at Airbnb homes.”

In a matter of weeks, hundreds of people started listing their Denver apartments on Airbnb for visitors to rent. Airbnb allows users to rent out everything from an extra room to a separate home.

“Had it not been for the DNC, it’s hard to know what Airbnb would be today,” Chesky told CNNMoney. “These things, it’s hard to get them going and you need a big kind of pop.”

While LinkedIn held off on all PR until it had 40,000 members and had already raised its first round of institutional financing from Sequoia Capital, once the company started its PR, it used a similar strategy to Airbnb. Instead of focusing on the overall service and how it worked, LinkedIn would pitch reporters on stories about members who found a job through LinkedIn. The company also rolled out the PR primarily through local media channels and focused on successful job searches in the home city of the reporter to whom the company was making a pitch. This allowed LinkedIn to present the value of its platform and the LinkedIn experience to the press as something much more concrete.

Double Trigger Type 3: A Competitor Makes a Mistake

Sometimes the event that acts as a catalyst is actually a misstep by a competitor. To me, the case of Movable Type vs WordPress is actually one of the most interesting examples of an event catalyzing growth. Specifically, Movable Type’s May 2004 decision to change the terms of its license.

In a Forbes magazine story eight years later, reviewing WordPress’s early history, author J. J. Colao explained:

In a field dominated by Movable Type, their service [WordPress] attracted thousands of users through word of mouth. After Movable Type’s owners decided to charge users in 2004, WordPress attracted a deluge of incensed refugees fleeing the company. By that August WordPress boasted 15,000 users and a pack of loyal developers refining code for free around the world.

As Movable Type Product Manager Byrne Reese explained in his blog postmortem later:

. . . what users feared most of all, is a repeat of exactly what happened the day Movable Type announced its licensing change: one day waking up to the realization that you owe some company hundreds, if not thousands of dollars and not being able to afford or justify the cost monetarily or on principle.

Science of Growth Book ReviewIt’s clear that Byrne is absolutely right. When you go back now and look at the early reaction, that fear is clear, and WordPress definitely used it to their advantage. For example, Ari Paparo, now a startup CEO and at the time an Internet marketing consultant, wrote a post titled “Time to Update the PowerPoint” in which he said:

As part of my consulting work I’ve implemented several corporate blogs, both as intranet and external solutions. In every case, I pitched some of the big advantages to MT:

  • Low cost license
  • Flexible, no restrictions
  • Easy to create multiple blogs
  • Easy to add new users

Well, that’s all shot to hell.

It would be easy to misinterpret the recommendations of this chapter as: Just work hard and hope you get lucky with a large event. Instead, I think you need to take the steps described to look for opportunities to exploit.

Excerpted with permission by St. Martin’s Press from The Science of Growth: How Facebook Beat Friendster– and How Nine Other Startups Left the Rest in the Dust by Sean Ammirati. Copyright 2016.

* This article contains affiliate links.

Extract from Science of Growth

Extract from Science of Growth

You'll also like:

  1. Launch of Project Management in the Real World! I heard from the publishers today that the first copies of Project Mangement in the Real World have come off the press and are looking...
  2. The Science of Growth [Book Review] Do you work in a startup, or digital project management? This might be the book you are looking for. It explains why some companies take...
  3. PRINCE2:2009: The Launch Please be patient with the video: it takes a while to load.  More notes from the launch event will be here in the days that...
  4. Project Management in the Real World launch The kind folks at the British Computer Society are throwing a bash for me to launch my new book, Project Management in the Real World....
  5. Launch in the city Remember the new London women’s networking group, WeAreTheCity?  Their launch event was a huge success:  hundreds of women queuing around the Monument branch of House...

Categories: Blogs

Mindful Project Management

Project Management Articles - PM Hut - Tue, 06/21/2016 - 18:13
Mindful Project Management By Diana Eskander What is mindfulness? Well, one thing we know for sure is that it’s a pretty hot topic these days. A simple definition of mindfulness is being present and aware of what’s happening internally and externally in our surrounding environments, right now, in this very moment. The Merriam-Webster dictionary defines it as “the practice of [...]
Categories: Communities