Skip to content

Feed aggregator

4 Ways LiquidPlanner Gantt Charts Are Smarter

The LiquidPlanner Blog - 9 hours 39 min ago
gantt chartHiRes

Since its introduction in the 1910s, the Gantt chart has remained a staple of the project manager’s tool set. Today, it’s still the go-to way of graphically displaying all of the tasks that make up a project and their progress towards completion.

Traditionally geared towards the planning of large-scale Waterfall-type engineering projects, Gantt charts are now also being adapted for use in Agile and other more dynamic environments; they’re featured in just about every piece of project management and planning software out there. You can even create Gantt charts in applications like Microsoft Excel, though it does beg the question of why when there are hundreds of better-suited tools for the job. It’s like choosing Word as your spreadsheet program.

But how does the elder statesman that is the Gantt chart fit into the vibrant, youthful, fast-moving world of Agile and more dynamic projects and still get the respect and attention it’s due? In truth, only by learning some new tricks.

Historically, Gantt charts have been the product of a deterministic approach to planning—a process that doesn’t fit smoothly into a project environment where uncertainty is endemic and change is guaranteed. Chances are, the first Gantt chart you generate is also the last, because it simply can’t keep pace with the work being done. And so, just like many schedules that came before, it quickly falls into disuse.

Smarter, more relevant Gantt charts

LiquidPlanner tackles this Gantt chart issue in a unique way by employing a predictive scheduling methodology that provides you with a visual schedule that takes uncertainty into account and removes the need for constant date changing.

Here are four ways that LiquidPlanner’s Gantt charts are different, and why they’re smarter.

1. Flexible finish dates

gantt 1


Gantt bars are Gantt bars right? They all show the planned start and finish date for each plan item; they show dates entered by someone based on when they think work can start and how long it will take. You pick a finish date and cross your fingers, hoping that the bar on the chart is close to being realistic.

Not so with LiquidPlanner. Their Gantt-style bars, which are called schedule bars, show a range of possible finish dates that are automatically calculated by the scheduling engine based on the best case and worst case work estimates entered for a task. The expected finish [E] is the mid-point between the two.

Gantt 2

The range of dates that the schedule bar represents allows you to see the uncertainty expressed in the underlying ranged estimate. The schedule bars highlight remaining work only, since you need to be focused on the work that still needs doing—not what’s been done.

Drift the mouse anywhere over the schedule bar and you’ll get a pop-up showing the expected finish:

gantt 3

And if you click on the bar itself you’ll get further data for that task or project:

gantt 4

All the information you need with just a few clicks.

2. Automatic updates

The LiquidPlanner schedule is updated automatically in real-time as team members log the work that’s been completed and revise the remaining work estimates.  And this is all reflected in the schedule bars that show all the work progress for every task that rolls up to a project.

There is no need for the schedule owner to manually update progress or check in updates received from others. If a task that’s scheduled to be completed today isn’t marked as complete today, it will be automatically rescheduled to be worked on tomorrow, again; with no need for any manual date tweaking. You’re not relinquishing control of your schedule; you’re relinquishing the need to spend half your life updating start and finish dates as tasks shift and change. And you have a schedule that stays relevant because it keeps up with the pace of the work.

3. No web of dependencies

Dependency management alone can be enough to make schedule management a full-time job; get just one wrong and your schedule could be seriously screwed. All those links can make your Gantt chart look awfully messy too:

gantt 5

LiquidPlanner uses “always-on” automatic resource leveling so there’s no need to set up manual dependencies between tasks assigned to the same team member; instead, tasks will be scheduled one after the other based on their priority order in the workflow. If you do need to set up a dependency for other reasons, these are indicated by blue dots after the task. Click on these dependencies and you get a popup showing the dependent task and a link that will jump you to it.

gantt 6

The good news here is that there’s no risk of double-booking a team member and no cobweb of lines across your planning work of art.

4. Schedule placeholders, streamlined view

One of the trickiest planning exercises at a project’s outset is deciding the who’s doing what. Often it will be impractical to craft a fully resource leveled plan for the project’s duration. Often it will be unnecessary. For example, if you’re just about to kick off Sprint 1, do you really need to establish who’ll be implementing which feature in Sprint 10? You probably don’t know which features you’ll even be building that far down the road.

If that’s the case, you can include tasks in your plan and keep them unassigned, so they’ll show as “Unscheduled.”

gantt 7

You won’t have a schedule bar for something that you have no idea about when or if will happen. Another tactic you can use is to put these tasks “On Hold” or stash them in a Backlog Package until you’re ready to get busy planning and working on them. Whichever mode you choose, you won’t busy up your Gantt view until you’re ready to go.

gantt 8

LiquidPlanner breathes new life into the Gantt chart in a dynamic and practical fashion. This approach allows you to focus fully on what’s left on your plate, i.e., the real work left to do and when it can realistically be done. You can get your schedule bar view, always updated, without the need to spend hours maintaining the plan. Whether you’re Waterfall, Agile, Agifall or some new yet unnamed method, LiquidPlanner will keep up with you and your team without breaking a sweat.

Learn more about Reading the LiquidPlanner Schedule Bars and their home base, the Timeline View in the LiquidPlanner Help Center.

Our smart schedule bars provide the most reliable and realistic Gantt chart experience you’ll ever have. How do we do it? Find out by downloading our eBook, “Introduction to Dynamic Project Management.”

Intro to Dynamic PM

The post 4 Ways LiquidPlanner Gantt Charts Are Smarter appeared first on LiquidPlanner.

Categories: Companies

The Appearance of Non-Leaders

Project Management Articles - PM Hut - 11 hours 31 min ago
The Appearance of Non-Leaders By Jeremy Francis I suppose it is not surprising that when there is a leadership vacuum all sorts of non-leaders seek to fill it! Much has been written about leaders but what about non-leaders? Well here is my attempt at identifying non-leaders in a leadership contest. Use the following eight descriptions to weed [...]
Categories: Communities

Virtual Leadership [Book Review]

Virtual Leadership book review

I work in a virtual team. In both my jobs, as a project manager and as a writer, I work in virtual teams, sometimes leading them, sometimes not.

That’s why I was keen to read Virtual Leadership by Penny Pullan, and I was lucky enough to get an advance copy before it hit the shelves. I read it in one sitting on a long train journey – it’s easy to get into so it doesn’t feel like hard going to plough through it.

I’m also lucky enough to know Penny and I can tell you that the book reads very much as Penny talks: knowledgeable, accessible, practical, and – if this doesn’t sound too sycophantic – wise.

So, in the normal style of my book reviews, let me tell you more about what’s in the book and what else I thought about it.

What Is A Virtual Team?

Penny says that it’s important to define virtual work before you understand what virtual teams are. Virtual work, she writes, is:

Work done by people who are geographically distributed, working together despite the fact that at least one person is not in the same location as others. Virtual work is supported by communications technology that helps people to connect when far apart.

A virtual team, then, is any team that works like that.

What Is Virtual Leadership?

The third concept defined pretty early on is virtual leadership, which you’d expect, what with it being the title of the book and all. Virtual leadership is defined as:

Being able to engage people from afar to produce results together. It builds on a shared vision of the future to help people to get things done together.

Virtual leadership is being able to engage people from afar to produce results together @pennypullan
Click To Tweet

Building Strong Virtual Relationships

Building strong team relationships over distance is key to being able to lead effectively virtually and it’s covered extensively in the book. There are plenty of tips.

I read these sections thinking, “But I do all this.” But I don’t really. I might have been aware of the techniques and used some of them in the past but it’s very easy to get lazy. And it’s clear that I’m often lazy.

This book is a good way to call yourself out on behaviours you know you should do. None of them are truly revolutionary if you’ve been around virtual teams for a while, but as a set of best practices they are useful to refer to and it’s super easy to up your game and increase your effectiveness if you actually do them.

Penny Pullan quote

Managing What Matters: Culture, Language, Time Zones

Culture, language and time differences are often the most important things for leaders to take into consideration because their team members really care about them. Over half respondents to Penny’s research survey for the book reported that cultural differences were a key challenge for virtual working.

There is a whole section in the book dedicated to this. There are again lots of practical tips like building pauses into the agenda to allow non-native English speakers time to reflect and soak in the point in their own language.

I found reading Virtual Leadership in one sitting meant I was hearing some of the tips, in a slightly different context and to illustrate a slightly different point, but the same tip nevertheless, several times. On example was to use the first 5 minutes of a call to do social chit chat. This turned up in several places, including (if my memory is correct) the discussion of the culture of time, challenges facing virtual leaders and how to run a virtual meeting.

As the book is designed to be something you return to time and time again, pulling out the strategies for the struggles you are facing today, I understand that it’s got to be like that. Just be aware that if you do like me and read it in one sitting there are a few best practices that are repeated.

Easy Retrospectives

One of my favourite tips from the book is for easy retrospectives. I love post-implementation reviews, and one of my own books, Customer-Centric Project Management was inspired by wanting a better way to do them. That’s why I think I’m so drawn to the idea of a lessons learned meeting that takes 5-10 minutes.

Penny says that you can ask your team two questions:

  • What’s going well?
  • What do you wish?

By framing the second point as: “I wish that…” you are turning it into a positive and helping people focus on what the better alternative to the status quo could be.

(As an aside, this also seems to be a strategy for parenting: instead of saying ‘you can’t have a biscuit’ you can say ‘I wish I could give you a biscuit’. I am trying this with my toddlers and it makes me feel better. I can’t tell if it is having any discernible effect on them yet but I’ll keep trying.)

Make It Real

I love how Virtual Leadership is written pragmatically, with the author suggesting that if you are short of time you skip to Chapter 8 to pick up the key strategies that are most appropriate for the leadership challenges you are facing today.

Each chapter ends with questions for reflection so that you can take the myriad of tools and ideas and start to think about how they would make a difference for you, in your personal situation.

This is not a book simply for project teams. In fact, it’s not written for a project management audience at all, so if you are expecting lots of context about projects you’ll be disappointed. It’s for anyone who works virtually, and that will include a lot of project teams. You don’t even have to be in a formal leadership position to get something out of it.

Pragmatic and practical, this book will help you avoid horrible conference calls and quickly boost productivity wherever your team are based.

Book review of Virtual Leadership by Penny Pullan

Book review of Virtual Leadership by Penny Pullan

You'll also like:

  1. 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...
  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. Book review: Trust in Virtual Teams Trust matters because it helps build a resilient project team. It helps get things done. Trusted team members not only do only what is asked,...
  4. Book Review: Business Analysis & Leadership Business analysis has come of age. If change programmes are to be successful, then problem solving, stakeholder engagement, business cases and situational analysis are essential....
  5. 3 Things that make a project team virtual “Virtuality…is a critique on how work gets done,” writes Thomas P. Wise in his book, Trust in Virtual Teams. Before I read the book I...

Categories: Blogs

A Project Management Mystery Solved

Project Management Articles - PM Hut - Fri, 07/22/2016 - 17:38
A Project Management Mystery Solved By James Young Executive Summary: Do not assume that your company’s management or the project stakeholders have a firm grasp on the methods and procedures of Project Management. It may be that they don’t know what they don’t know about the methods and procedures. Be prepared to develop Project Execution Plan (PEP) [...]
Categories: Communities

From The PMI Power Talks [Video]

Here’s my video diary of the PMI Power Talks this week (about 4 minutes, safe for work).

Hosted by the PMI UK Chapter in London, the Power Talks brought together 4 fantastic speakers for an afternoon of discussion and debate focused on strategy execution.

I think this is the link to the replay of the event: but it was all afternoon so be prepared to flick through the video as you don’t want to be sitting there for 4 hours.


You'll also like:

  1. APM Conference Diary [Video] Here's my video diary from the APM Conference 2016. I've strung together my live Periscope broadcasts from the day to give you an idea about...
  2. Video Diary: PMI Congress Day 2 This is the video diary of yesterday’s Congress exploits, with the highlight being the peanut butter and jelly sandwiches we got in the afternoon break. ...
  3. Video Diary: Pink Elephant ITSM Conference Day 3 This is the video from the Tuesday at the Pink Elephant ITSM Conference in Las Vegas. The video is about 6 minutes long and includes...
  4. Video Diary: PMI EMEA Global Congress 2016 Watch my video diary to find out what went on during PMI EMEA Global Congress 2016 in Barcelona....
  5. PMI Synergy Conference: video diary Here is my video diary of my day at the PMI Synergy event for International Project Management Day. In it you’ll see Lord Digby Jones,...

Categories: Blogs

Legendary Leadership Secrets - Success Eats Charisma for Lunch

Project Management Articles - PM Hut - Thu, 07/21/2016 - 22:05
Legendary Leadership Secrets - Success Eats Charisma for Lunch By David Roppo For many decades the phrase “Culture eats strategy for breakfast,” has been floating around leadership development circles. It’s often attributed to Peter Drucker, the father of management, although that claim has yet to be substantiated. Nevertheless, I believe the phrase makes for some validate points. [...]
Categories: Communities

Asana Culinary: meet the team that feeds productivity

Asana Blog - Thu, 07/21/2016 - 19:33
culinary edited

Ask an Asana employee what their favorite time of day is, and you’ll probably hear “breakfast, lunch and dinner.” After all, meals are an opportunity to step away from work and socialize. But at Asana, meals are even more than that. The culinary program literally provides the fuel required to build our product and is at the core of how Asana empowers teams to do great things.

Asana’s culinary philosophy

We provide our staff with nutritionally balanced meals three times a day. Our skilled chefs and nutrition team plan menus around ingredients that keep us energized and working at our highest potential. Most ingredients are locally sourced from sustainable and organic farms and our recipes are adapted to include fresh vegetables, healthy fats, and natural sweeteners.

This means individuals on our staff don’t have to worry about nutritional balance or crashing mid-afternoon after a heavy meal. It saves time and money too, since Asanas don’t worry about groceries or cooking at home and packing a lunch; it’s hard to put a dollar amount on the value our culinary team provides.

It all started with a man cooking in his own kitchen. Donnie Thompson, who leads the program, has grown it to include a fully equipped commercial kitchen, our own 125 seat Cafe Luna, and a team of 12.

We sat down with a few members of the culinary team to see what’s cooking in the Asana kitchen and how this program is essential to our company’s success.

The culinary program literally provides the fuel required to build our product and is at the core of how Asana empowers teams to do great things.

How did the culinary program get started?

Chef Donnie: “When JR [our co-founder] said he wanted a chef for 13 people and I was referred, I told him he didn’t need one. But he was adamant about starting a food program early on, making it a focal point not just for the team’s health and well being, but also as part of the culture.

Who is behind the program?

Chef Donnie: “We’ve got a unique team of talented, passionate people who truly care about the food they’re making. Because our team is both back and front of the house, and we serve the same people every day, we’re committed to doing our best and having fun while we’re at it. ”

Chef Amy: “Our work is great compared to a restaurant, where there’s so much pressure on every little thing. Because a lot of the stresses are removed, we can turn on our music, joke around, and just cook.”

Because our team is both back and front of the house, and we serve the same people every day, we’re committed to doing our best and having fun while we’re at it.

What sets Asana Culinary apart from other food environments you’ve seen or experienced?

Chef Amy: “We have the freedom to do cool stuff. We don’t have any  constraints on the type of cuisine we serve, and we’re encouraged to try lots of different things.”

Chef Kim: “After visiting an Asana customer, I now understand how much we impact other companies. Since then I take even more pride in working at Asana and in making sure everyone is happy and healthy.”

Chef Wade: “Our work environment is amazing. People are always thanking us, our benefits program encourages us to become better people, and we’re able to put our creativity into something that will improve the lives of our team.”

What’s your favorite thing about life in the kitchen?

Chef Wade: “We have a family meal every day. Right after lunch, everyone sits down for a break, chats, and gets to relax. It’s nice to get the whole team together when we’re not cooking or serving.”

Chef Amy: “Music is the lifeblood of our day in the kitchen. We listen to all kinds of music and every once in awhile someone will just rock out. We don’t take ourselves seriously at all.”

Chef Kim: “We joke around with one another, whether it’s hiding each other’s Halloween candy or having water gun fights on someone’s birthday. We’re like a family.”

What role does nutrition play in meals at Asana?

After getting questions about nutritional value and experiencing a growing team with dietary restrictions, Asana decided to bring on culinary nutritionist, Leandra Rouse, of TuneUp Wellness. She supports the team in expanding their understanding of nutritional science.

Leandra’s program has also served to educate Asanas across the company, offering a monthly workshop with a different focus. In January, there was a “Debunking detox” workshop, and before flu season, an immunity workshop.

Leandra: “Beyond education, having a culinary nutritionist advising your team helps ensure that everything coming from the kitchen is done intentionally. For example, before a big launch we serve more brain-supporting foods; your daily breakfast is rich in protein & complex carbs for all-day energy; and you get house-made, nourishing afternoon snacks to help you stay focused and energized.”

What are you excited about for the future of Asana Culinary?

Chef Donnie: “We’re growing across all of our locations—San Francisco, New York, and Dublin—and I’m excited to make sure that all of our products are picked out mindfully. It’s an exciting challenge to scale and stick to our values.”

Chef Kim: “We’ve opened our office on the third floor, and we now have a barista! As the company grows, so does the culinary team, and we’re lucky to be in a position to meet new asanas as they join, whether it’s in Cafe Luna or at the coffee bar.”

Chef Wade: “I’m really excited for our increased focus on what we’re sourcing and where it’s coming from. We’re going to educate Asanas on where their meats are coming from, helping the entire company learn about farms, animals, and best practices. I even think vegans and vegetarians would appreciate this information!”

I’m really excited for our increased focus on what we’re sourcing and where it’s coming from.

We’re really proud of our culinary team and the culture they foster. It’s an investment of resources and time, but the impact it has on our team is palpable and well worth it. If you’d like to stay abreast of what they’re cooking for us through photos, menus, and recipes, like their page on Facebook or follow them on Instagram. What does your company do to stay nourished, healthy, and productive? Tell us in the comments.

Interested in building the future of work with us (and joining us at mealtime)? We’re hiring.

Categories: Companies

Quote of the Day

Herding Cats - Glen Alleman - Thu, 07/21/2016 - 19:03

A skeptic will question claims, then embrace the evidence. A denier will question claims, then reject the evidence. - Neil deGrase Tyson

Think of this whenever there is a conjecture that has no testable evidence of the claim. And think ever more when those making the conjectured claim refuse to provide evidence. When that is the case, it is appropriate to ignore the conjecture all together 

Categories: Blogs

Report Roundup: 5 Project Reports You Don’t Want to Miss and How to Use Them

The LiquidPlanner Blog - Thu, 07/21/2016 - 17:00
project reportsproject reports

It’s been a busy summer here at LiquidPlanner headquarters! Just a couple of weeks ago, we released some product updates that we’re pretty excited about. We made big improvements to workload visualization and forecasting, and added a new way to find and run reports from the main projects view.


One report, in particular, got a major upgrade — it’s called the Project Workload report and it’s been the star of the show because it provides a simple and effective way to manage your project team and their assignments. We put this report in the spotlight by adding a new Reports menu on the Projects tab to make it easy to access while you’re monitoring your projects. In the same menu, you’ll find a supporting cast of powerful reports that have been around for some time. While these reports aren’t new, they’re great for understanding what’s happening with your projects and visualizing changes in the plan.

Read on to learn about Project Workload, Project Status, Remaining Trend, Total Trend, and Date Drift and find out why these reports have taken center stage in your workspace.

Project Workload

Project Workload is your resourcing crystal ball. It instantly shows you who’s working on a project, how much work they have left, and when they’ll be working on it. One of the best things about this report is that you can run it for client work, a specific initiative, or even multiple projects and get workload visibility across all of them.


The report puts the person who is expected to finish last at the top, so you know whose work is driving the end date of the project. It also highlights who’s putting the project at risk and gives you actionable information that helps you shift work around and load balance to keep the project on track.

For more details about the Project Workload report, read this Help article.

Project Status

The Project Status report summarizes some of the most important data about your project. You can see the overall progress, milestone dates, how much work has been done and by who.

This report is useful when you need a quick overview that you can share with the project team.


For more details about the Project Status report, read this Help article.

Remaining Trend

If you want to show off the project team’s progress to your stakeholders, run the Remaining Trend report. Think of this report as a dynamic burndown chart. It shows how the estimated remaining work for a project has changed over time and shows you the probable landing zone. Ideally, the plotted lines should slope downwards, which would mean that the remaining work for the project is decreasing as time goes on — just what every stakeholder wants to see!


If the lines jump upwards, that’s a sign of either added scope or consistent underestimation of tasks. If they jump downwards, that might mean that scope was cut to meet the deadline or that your team is logging a bunch of hours all at once, instead of as they go.

For more details about the Remaining Trend report, read this Help article.

Total Trend

The Total Trend report is the best way to understand changes in overall scope. The report plots the total amount of work, the range of uncertainty for a project, and the amount of work that’s been completed over time.

The goal is to keep the scope as close to the agreed upon plan as possible, so in a healthy project, you’ll see the plotted lines in the report to stay flat and narrow continuously. You also want the green shaded area to grow steadily and eventually meet the total trend lines, which means that your team is making consistent progress and getting work done. If this is what you see in your report, do a victory dance — it’s difficult to achieve!


For most projects, you’ll see the plotted lines move upwards and downwards as the project progresses. A little variation is okay, but drastic spikes are a sign of adding or cutting scope. Dig in to find out what happened and make sure that you can still finish on time without compromising the quality or deliverables of the project.

For more details about the Total Trend report, read this Help article.

Date Drift

Date Drift, also known as the slip report, gives you a simple visual for how the calculated finish date of a project has changed over its lifetime.

You want the black Expected line to stay flat, which would mean that your finish date has stayed the same. The report below shows a more common scenario — the project’s expected finish date blew past its deadline in red. Then, the deadline was renegotiated and pushed back by a few days. Now, it looks like the project will finish under the new deadline despite it slipping by a couple of weeks from its initial projections.


For more details about the Date Drift report, read this Help article.

And that’s a wrap!

Complex projects can take some pretty wild turns and cause unpleasant surprises if you’re not using the right tools. Make sure to stay ahead of the game with these five reports, all easily accessible from the Projects tab. Click on the Reports menu in your workspace and take ‘em for a spin!

Resource management is a many-headed beast, and getting the people part of it mastered could be what sets you apart in your career. To learn more tricks and skills, download our eBook, “5 Best Practices to Manage Project Resources Effectively.”

resource management ebook


The post Report Roundup: 5 Project Reports You Don’t Want to Miss and How to Use Them appeared first on LiquidPlanner.

Categories: Companies

Making Release Frictionless, a Business Decision, Part 2

In Part 1, I talked about small stories/chunks of work, checking in all the time so you could build often and see progress. That assumes you know what done means. Project “done” means release criteria. Here are some stories about how I started using release criteria.

Back in the 70s, I worked in a small development group. We had 5 or 6 people, depending on the time of year. We worked alone on our parts of the system. We all integrated into one instrument, but we worked primarily alone. This is back in the days of microcomputers. I wrote assembler, Fortran, or microcode, depending on the part of the system. I still worked on small chunks, “checked in,” as in I made sure I saved my files. No, we had no real version control then.

We had a major release in about 1979 or something like that. I’d been there about 15 months by then. Our customers called the President of the company, complaining about the software. Yes, it was that bad.

Why was it that bad? We had thought we were working towards one goal. Our customers wanted a different goal. If I remember correctly, these were some of the problems (that was a long time ago. I might have forgotten some details.):

  • We did not have a unified approach to how the system asked for information. There was no GUI, but the command line was not consistent.
  • Parts of the system were quite buggy. The calculations were correct, but the information presentation was slow, in the wrong place, or didn’t make sense. Our customers had a difficult time using the system.
  • Some parts of the system were quite slow. Not the instrument, but how the instrument showed the data.
  • The parts didn’t fit together. No one had the responsibility of making sure that the system looked like one system. We all integrated our own parts. No one looked at the whole.

Oops. My boss told us we needed to fix it. I asked the question, “How will we know we are done?” He responded, “When the customers stop calling.” I said, “No, we’re not going to keep shipping more tape to people. What are all the things you want us to do?” He said, “You guys are the software people. You decide.”

I asked my colleagues if it was okay if I developed draft release criteria, so we would know that the release was done. They agreed. I developed them in the next half day, wrote a memo and asked people for a meeting to see if they agreed. (This is in the days before email.)

We met and we changed my strawman criteria to something we could all agree on. We now knew what we had to do. I showed the criteria to my boss. He agreed with them. We worked to the release criteria, sent out a new tape (before the days of disks or CDs!) to all our customers and that project finally finished.

I used the idea of release criteria on every single project since. For me, it’s a powerful idea, to know what done means for the project.

I wrote a release criteria article (see the release criteria search for my release criteria writing) and explained it more in Manage It! Your Guide to Modern, Pragmatic Project Management.

In the 80s, I used it for a project where we did custom machine vision implementations. If I hadn’t, the customer would have continued asking for more features. The customer did anyway, but we could ask for more money every time we changed the release criteria to add more features.

I use release criteria and milestone criteria for any projects and programs longer than three months in duration, so we could see our progress (or lack thereof) earlier, rather than later. To be honest, even if we think the project is only a couple of months, I always ask, “Do we know what done means for this project?” For small projects, I want to make sure we finish and don’t add more to the project. For programs, I want to make sure we all know where we are headed, so we get there.

Here’s how small chunks of work, checking in every day, and release criteria all work together:

  1. Release criteria tell you what done means for the project. Once you know, you can develop scenarios for checking on your “doneness” as often as you like. I like automated tests that we can run with each build. The tests tell us if we are getting closer or farther away from what we want out of our release.
  2. When you work in small chunks, check them in every day and build at least as often as every day, you can check on the build progress. You know if the build is good or not.
  3. If you add the idea of scenarios for testing as you proceed, release becomes a business decision,  not a “hardening sprint” or some such.

Here’s a little list that might help you achieve friction-less releases:

  1. What do you need to do to make your stories small? If they are not one day, can you pair, swarm, or mob to finish one story in one day? What would you have to change to do so?
  2. If you have curlicue stories, what can you do to make your stories look like the straight line through the architecture?
  3. What can you do to check in all the time? Is it a personal thing you can do, or do you need to ask  your entire team to check in all the time? I don’t know how to really succeed at agile without continuous integration. What prevents you from integrating all the time? (Hint, it might be your story size.)
  4. Do you know what done means for this release (interim and project)? Do you have deliverable-based planning to achieve those releases?

Solve these problems and you may find frictionless release possible.

When you make releasing externally a business decision—because you can release internally any time you want—you will find your project proceeds more smoothly, regardless of whether you are agile.

Reminder: If you want to learn how to  make your stories smaller or solve some of the problems of non-frictionless releases, join my Practical Product Owner workshop, starting August 23, 2016. You’ll practice on your projects, so you can see maximum business value from the workshop.

Categories: Blogs

Making Release Frictionless, a Business Decision, Part 1

Would you like to release your product at any time? I like it when releases are a business decision, not a result of blood, sweat, and tears. It’s possible, and it might not be easy for you. Here are some stories that showed you how I did it, long ago and more recently.

Story 1: Many years ago, I was a developer on a moderately complex system. There were three of us working together. We used RCS (yes, it was in the ’80s or something like that). I hated that system. Maybe it was our installation of it. I don’t know. All I  know is that it was too easy to lock each other out, and not be able to do a darn thing. My approach was to make sure I could check in my work in as few files as possible (Single Responsibility Principle, although I didn’t know it at the time), and to work on small chunks.

I checked in every day at least before I went to lunch, once in the middle of the afternoon, and before I left for the day. I did not do test-first development, and I didn’t check my tests in at the time. It took me a while to learn that lesson. I only checked in working code—at least, it worked on my machine.

We built almost every day. (No, we hadn’t learned that lesson either.) We could release at least once a week, closer to twice a week.  Not friction-less, but close enough for our needs.

Story 2: I learned some lessons, and a few years later, I had graduated to SCCS. I still didn’t like it. Merging was not possible for us, so we each worked on our own small stuff. I still worked on small chunks and checked in at least three times a day. This time, I was smarter, and checked in my tests as I wrote code. I still wrote code first and tests second. However, I worked in really small chunks (small functions and the tests that went with them) and checked them in as a unit. The only time I didn’t do that is if it was lunch or the end of the day. If I was done with code but not tests, I checked in anyway. (No, I was not perfect.) We all had a policy of checking in all our code every day. That way, someone else could take over if one of us got sick.

Each of us did the same thing. This time, we built whenever we wanted a new system. Often, it was a couple of times a day. We told each other, “Don’t go there. That part’s not done, but it shouldn’t break anything.” We had internal releases at least once a day. We released as a demo once a week to our manager.

After that, I worked at a couple of places with home-grown version control systems that look a lot like subversion does now. That was in the later 80s. I became a project manager and program manager.

Story 3: I was a program manager for a 9-team software program. We’d had trouble in the past getting to the point where we could release. I asked teams to do these things: Work towards a program-wide deliverable (release) every month, and use continuous integration. I said, “I want you to check everything in every day and make sure we always have a working build. I want to be able to see the build work every morning when I arrive.” Seven teams said yes. Two teams said no. I explained to the teams they could work in any way they wanted, as long as they could integrate within 24 hours of seeing everyone else’s code. “No problem, JR. We know what we’re doing.”

Well, those two teams didn’t deliver their parts at the first month milestone. They were pissed when I explained they could not work on any more features until they integrated what they had. Until they had everything working, no new features. (I was pissed, too.)

It took them almost three weeks to integrate their four weeks of work. They finally asked for help and a couple of other guys worked with the teams to untangle their code and check everything in.

I learned the value of continuous integration early. Mostly because I was way too lazy (forgetful?, not smart enough?) to be able to keep the details of an entire system in my head for an entire project. I know people who can. I cannot. I used to think it was one of my failings. I now realize many people only think they can keep all the details. They can’t either.

Here’s the technical part of how I got to frictionless releases:

  1. Make the thing you work on small. If you use stories, make the story a one-day or smaller story. I don’t care if the entire team works on it or one person works on it (well, I do care, and that’s a topic for another post), but being able to finish something of value in one day means you can descend into it. You finish it. You come up for air/more work and descend again. You don’t have to remember a ton of stuff related but not directly a part of this feature.
  2. Use continuous integration. Check in all the time. Now that I write books using subversion, I check in whenever I have either several paras/one chunk, or it’s been an hour. I check that the book builds and I fix problems right away, when the work is fresh in my mind. It’s one of the ways I can write fast and write well. Our version control systems are much more sophisticated than the ones I used in the early days. I’m not sure I buy automated merge. I prefer to keep the stories small and cohesive. (See this post on curlicue features. Avoid those by managing to implement by feature.)
  3. Check in all the associated data. I check in automated tests and test data when I write code. I check in bibliographic references when I write books. If you need something else with your work product, do it at the time you create. If I was a developer now, I would check in all my unit tests when I check in the code. If I was really smart, I might even check in the tests first, to do TDD. (TDD helps people design, not test.) If I was a tester, I would definitely check in all the automated tests as soon as possible. I could then ask the developers to run those tests to make sure they didn’t make a mistake. I could do the hard-to-define and necessary exploratory testing. (Yes, I did this as a tester.)

Frictionless releases are not just technical. You have to know what done means for a release. That’s why I started using release criteria back in the 70s. I’ll write a part 2 about release criteria.

Categories: Blogs

Big Data For Construction: How It Can Help You Deliver Your Project On Time

Big data and constructionBig Data for construction is here - the question is are you ready?But first, what is Big Data? At the AACE Conference last month in Toronto, the keynote speaker was Paul Zikopoulos, a trends expert and VP of Big Data Analytics at IBM.Big Data is a ubiquitous term that refers to the immense amount of data we capturing about all of our interactions online or with devices. Every click online is captured somewhere in a database, not to
Categories: Blogs

How to Become a More Challenging Project Leader

The LiquidPlanner Blog - Wed, 07/20/2016 - 17:17
project leadership 2

If you want to be a strong project manager and leader, you need to know how to challenge and support your team members in equal measure. This means that you are able to set clear performance targets that stretch the individual while at the same time providing them with the support they need to reach their targets. While it might sound easy in theory, it’s far more difficult in practice.

project leader

During my years of project management coaching, I’ve come across a large number of PMs who feel competent in the area of being supportive and nurturing, but find it far harder to be challenging and to set the standard. When these leaders try to challenge a team member—for example holding them accountable to goals—they often lose their confidence in the process, which leads to questioning themselves or stopping in their tracks because they fear that their words will be too harsh and hurtful.

Inside these leaders know what they want to say, but they have difficulties formulating the words because they worry they’ll either upset the other person or the words will be taken in the wrong way. As many project managers put a high value on personal relationships and harmony, they end up holding themselves back when they have to deliver a message that could be interpreted as critical. For some leaders, when they do say something direct or challenging, they become overly apologetic afterward and backtrack. The result: delivering mixed messages, which is not a strong position to lead from.

Why your team needs to be challenged

If you recognize yourself in the above description, you first need to consider that you may well be doing people a disfavor by not holding them to account. If you let people coast or get away with poor performance you are contributing to their decay.

For the most part, your team members will find it motivating to learn and grow and to know that you, their manager, will expect the best from them. In addition, these individuals will feel more confident and in demand if their skills, abilities and performance are on par with—or better than—that of their peers.

If you challenge people to stretch and move outside of their comfort zone in the right way, you’re helping them in their career. What you also need to remember is that with your continued support you team members will be well placed to meet the expectations you’re setting. I’m in no way implying that you should begin to be a hard-nosed boss and that you should stop being supportive.

Set expectations, agree on the outcome

A really big point, which I hope will help you to appropriately challenge your team, is that you need to mutually agree on performance expectations up front when you assign a task. It’s almost impossible to hold someone to account if you haven’t been explicit about the details of what was expected and what a good outcome looks like. It’s imperative however, that the performance expectations are mutually agreed upon, and that it isn’t just the project manager who sets the standard and decides what the task looks like and when it needs to get done by. If it’s a one-sided expectation exchange the team member will not buy into it and will not perform well.

But how do you agree to these performance expectations in a way that enables you to better challenge the team member? Let’s look at an example.

Let’s say that you want a team member to create a presentation, which she will give at the project kick-off meeting. As you delegate this task, ensure that you and the team member have mutually agreed on answers to the following questions:

  • What is the scope of the task? The first question you need to answer is what exactly the team member will deliver at the end of the assignment and what “good” looks like. To help you clarify what is expected from the presentation, make use of the MoSCoW method (Must have, Should have, Could have, Will not have). In this case it could mean that the presentation must be in PowerPoint, it must have 8-10 slides and it must be able to be presented within a timeframe of 20-30 minutes. Each slide should contain a visual element and should have a clear message or take away related to the topic. The presentation could be printed for each participant, but will not be provided in electronic format. The presentation will have screen shots but will not encompass a live demo. Before handing in the presentation it must be spell checked and should be peer reviewed.
  • How much effort is involved? Estimating how much effort is involved in creating the presentation will be much easier now that you have agreed to the scope of it by using the MoSCoW technique. The next step is to help the team member think through what the best case and worst case estimates are until you reach a realistic assessment. Don’t estimate the work for that person, but ask clarifying questions that help you both understand the reasoning behind the estimate.
  • When can the work be delivered? It’s important that you don’t set the deadlines and give team members full ownership of finish dates. What you can do instead is help people think through all the work that needs to be completed, what could slow things down, and from that information what date are reasonable to commit to. When team members set the deadlines themselves they’re more inclined to take ownership of reaching it and living up to it.
  • What could go wrong? Before you finalize finish dates, ask the team member to consider everything that could get in the way or prevent him from delivering the task at the agreed upon date. In other words, help team members think through all the risks involved and how to overcome or mitigate them. Not everyone is wired to think about their tasks and workload in a logical way, so use your skills to help them organize their work.
  • What support do you need? Now that you’ve agreed on what needs to get done, when it will be completed by and what the potential roadblocks are, it’s appropriate to ask the team member what support they need from you. Maybe she would like to practice a dry run of her presentation with you, or have the green light to ask someone a teammate to peer review it. If you want to stretch, challenge and hold your team member to account, you need to ensure you have done everything you can to set them up for success, so ask them what support they reasonably need from you or anyone else.
  • How, and how often will we check in? The last question is about how you’ll check in with individuals to assess progress. Regular one-on-ones are needed for team member to ask for guidance, feedback and support. What you don’t want is to come across as a controlling micromanager, so agree up front on how and how often you’ll meet and don’t overdo it.

For example, consider the following: Will you check in with each other every other day via telephone, once a week face-to-face or will the team member keep you updated with a weekly progress report. Agree to a form that will work for both of you and stick to it unless you agree otherwise.

Based on this kind of expectation exchange, it should be clear that you have set the team member up for success and given them the best possible conditions for delivering a great presentation. If an individual ends up not delivering what you both agreed to, you now have a contract to reference and a framework that will help you hold team members accountable.

The big difference with being an effective challenging leader is that you’re not holding them to your standers, but to the standards that you both agreed on. In truth, most people are happy to be held accountable for delivering results provided they have a say in their process and received support getting there.

Leading teams effectively is one of the many exciting project management challenges you face! To learn how to lead great teams and master the trickery of your job, download our eBook, “How to Solve the Top 9 Project Management Challenges.”

Solve the Top 9 PM Challenges


The post How to Become a More Challenging Project Leader appeared first on LiquidPlanner.

Categories: Companies

How to Fix Internet Explorer 11 File Download Failures

SEP Project Management Blog - Wed, 07/20/2016 - 17:14


  • Users received error “[filename] couldn’t be downloaded.” when attempting a file download in Internet Explorer 11


  • Using the .NET HttpResponse class instance method Close().


  • Replace Close() with End() method.

We had a problem with Internet Explorer 11 (IE11). Not something unheard of but, as always, quite puzzling. We were faced with the issue that clients were receiving “[filename] couldn’t be downloaded.” message when attempting file downloads in IE11. This issue couldn’t be repeated in Firefox or Google Chrome. Classic Internet Explorer.

Searching around led us to a Microsoft article that sounded like a promising lead towards a HTTP header issue. More specifically, we thought the issue was a combination of a HTTPS connection and cache-control in the header being set improperly. Adding to the complication was the fact that this was an ASP.NET application that also served some webpages as Perl cgi pages. The download issue only presented itself on the Perl cgi pages.

It turns out the issue was on the C# and ASP.NET side in a section of code that is only executed for non-HTML cgi web pages. Our offender was the method below.

protected void WriteRightNow(Stream cgiData)
    // Make sure there isn't anything else on its way to the client.

    // This is the only thing we're going to send to the
    // client, so there's no need to buffer it.
    Response.BufferOutput = false;

    // Write the generated content.

    // Close the output stream so the normal page won't be rendered.

The Response object is an instance of .NET’s HttpResponse class.  The final Close() method call is our perpetrator. The Close() method abruptly ends a connection to a client. According to Microsoft documentation the Close() method can also cause buffered data on both server and client side to be dropped.

It appears IE11 would buffer the download file and prompt the user for how to handle the file attempting to be downloaded. Our application would reach the Close() method before the user could choose an option and the buffered data would be dropped. Then when the user would go to select an option, they would receive a download failed error because the file data had already but deleted.

The solution is to use the End() method instead. This method stops data being sent to the client while ensuring they still receive any buffered data. This turns into a one line fix for our method.

protected void WriteRightNow(Stream cgiData)
    // Make sure there isn't anything else on its way to the client.

    // This is the only thing we're going to send to the
    // client, so there's no need to buffer it.
    Response.BufferOutput = false;

    // Write the generated content.

    // Close the output stream so the normal page won't be rendered.
Categories: Companies

Assessing Value Produced in Exchange for the Cost to Produce the Value

Herding Cats - Glen Alleman - Wed, 07/20/2016 - 13:35

A common assertion in the Agile community is we focus on Value over Cost.

Both are equally needed. Both must be present to make informed decisions. Both are random variables. As random variables, both need estimates to make informed decisions.

To assess value produced by the project we first must have targets to steer toward. A target Value must be measured in units meaningful to the decision makers. Measures of Effectiveness and Performance that can monetized this Value.

Value cannot be determined without knowing the cost to produce that Value. This is fundamental to the Microeconomics of Decision making for all business processes.

The Value must be assessed using...

  • Measures of 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.
  • Measures of Performance - is a Measure that characterize physical or functional attributes relating to the system operation, measured or estimated under specific conditions.
  • Key Performance Parameter - is a Measure that represents the capabilities and characteristics so significant that failure to meet them can be cause for reevaluation, reassessing, or termination of the program.
  • Technical Performance Measures - are Attributes that determine how well a system or system element satisfies or expected to satisfy a technical requirement or goal.

Without these measures attached to the Value there is no way to confirm that the cost to produce the Value will breakeven. The Return on Investment to deliver the needed Capability is of course.

ROI = (Value - Cost)/Cost

So the numerator and the denominator must have the same units of Measure. This can usually be dollars. Maybe hours. So when we hear ...

The focus on value is what makes the #NoEstimates idea valuable - ask in what units of measure is that Value? Are those units of measure meanigful to the decision makers? Are those decision makers accountable for the financial performance of the firm?


Categories: Blogs

5 Tips To Re-Energise Your Daily Standup Meetings

Reenergise your stand up

Regular readers will know that I’m not an expert in Agile, by any means. So I’m delighted to bring you this guest contribution by Elisa Cepale who lives and breathes this stuff in her day job. Elisa, over to you…

Elisa Cepale

Elisa Cepale

I facilitate daily standup meetings for our support team. When I started working for White October we followed the conventional “scrum” format, where the team get together, share what’s new, what’s challenging and what’s happening, and everyone gives feedback and makes suggestions to unblock each other.

We valued the idea that everyone feels involved and informed, and their contribution is valuable, and the opportunity to re-group as a team once a day.

So far so good, right?

Not really. Because after a few weeks I realised that the energy levels weren’t what they should be for such a creative, innovative agency.

Our projects at the time were interesting; everyone was communicating and sharing ideas.  But the traditional scrum format didn’t work for our team and made meetings flat. The team just wanted to get through them and get back to their desks.

We needed to inject some energy. I experimented with a few ideas, to see what worked and what didn’t.

Here’s a few that went down really well, and one or two that didn’t.

Activity 1: What made you unhappy yesterday and what will make you happy today?

This was a good way to start the day with a positive attitude, tease out team challenges and figure out how to overcome them. It also gave everyone the opportunity to make suggestions, and gave the scrum master visibility of what everyone was working on

Afterwards everyone shared a music track to create a playlist for the day to share with the rest of the agency. This introduced a type of gamification in the daily routine which improved the team communications and engagement.

Activity 2: 360 Degree Appreciation

I had this idea from Funretrospectives, and introduced it to the team the week before Christmas as a fun way to share gifts.

As a team everyone thanked each other for their work and said what they appreciated the most. It was really useful to speak out about why we value each other.

By subconsciously following one of the Fish Philosophy principles of “making someone’s day”, we realised that a little gesture of appreciation can go a long way, especially if it’s reciprocated.

A gesture of appreciation can go a long way especially if it’s reciprocated -> @firstwelove
Click To Tweet

Activity 3: It’s Monday! Give one positive thing about last week and what are you going to complete today

Starting the week with a positive outlook has become a tradition for our team. On Mondays it can take a while to get into the rhythm, but when we get into the scrum and reflect on the positive things from the previous week, we begin to interact with each other in a more productive way.

We suddenly realise that we have something to look forward to…

Activity 4: If you were a support ticket what would you be?

This was a quick exercise but it triggered us into thinking about ourselves and what we can improve in our approach to work. One of the team members said they would make sure a process is written down before tackling any job.

Constant reviews like this are an essential tool of agile development. No matter how good a team is, a bit of self-criticism opens up opportunities for improvement and self-awareness.

Activity 5: Write a postcard to a former colleague describing your day yesterday

This is a good game too that will harness a positive attitude and have fun at work. If you do this exercise I recommend having a different team member to read the postcard. Hearing what we all wrote helped us to think about it in a less abstract way and remember it better.

“Scrums feel more energised. Doing the ‘same-old’ each day can become a drag and you go into the scrums with the same mindset, now we don’t know what task/questions will be asked”. Adam, junior developer.

As a result of these activities our team has grown stronger and more enthusiastic. We appreciate the importance of getting together once per day to check progress and issues but also understand that this ceremony can be much more engaging. I now enjoy when my teammates slack me to remind me that it’s time for scrum.

Have you tried any of these or do you have ideas of your own you could share?

About the author: Elisa Cepale is a support administrator @WhiteOctober and founder of @FirstWeLove. As support administrator at White October she manages agile projects as well as supervising the ongoing support flow. She also contributes to creating long-lasting relationships with clients and a positive environment to work in. In her spare time, you can find Elisa in her studio where she blogs about weddings amongst other things, edits her photos, makes stuff, and plans her next trip abroad.

Reenergise your stand up

You'll also like:

  1. 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...
  2. 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....
  3. Debunking Agile Agile is: Change friendly Iterative Collaborative Chunked delivery Communications focused Business focused Scope tolerant Quality focused (if you do it correctly!) These were the themes...
  4. My Daily Routine Find out what I do in a day to try to keep my work/life balance in healthy check and fit everything in. How similar is...
  5. Effective Meetings: Reloaded This is a guest post by Guillermo Solis. Managing successful meetings is not a new subject, but neither is a waste of time to refresh...

Categories: Blogs

My first meeting with my project sponsor

Ron Rosenhead's Project Management Blog - Wed, 07/20/2016 - 08:16

This could be an interesting meeting as it is the first time you have met and you want this to go well, setting a good direction for the project. It follows then that you need to start thinking about the preparation that is required for this meeting.

There is a wide range of preparation you could do which means it really needs to be focused on what you want to achieve. This should include building  rapport with your sponsor alongside establishing some facts from your sponsor about the project.

What else should this preparation include?

  • Start by thinking and researching their experience. Is your sponsor a first timer or someone who has a solid history? Are they someone completely new to the company or someone with a ‘reputation?’ You need to gather information that starts to focus your mind on the person in the position of project sponsor.
  • Talk with other managers, other project sponsors, Ask about the successes and the challenges that the sponsor has faced, how the sponsor responded to any problems,
  • Establish how they have supported other project managers and the impact on the project and project manager
  • Also look for experience of leading and their management style – what comments have colleagues made?
Strategies for Project Sponsorship published by Management Concepts

Strategies for Project Sponsorship published by Management Concepts

  • Now think about how to build that all important relationship with the sponsor as well as your own. Do you take them to the pub (this was suggested at a speaking engagement and went down well!) or should you meet in private over a cup of coffee? The where you meet may well be detected by your earlier researches
  • Where you can, prepare an agenda which suits the 3 needs; the sponsors (ask?), yours as well as the project’s needs. Send it to the sponsor in advance of the meeting
  • In the meeting try and capture the vision the sponsor has about the project. It may at this early point be poorly formed however it is your job to help put some form around that vision later on
  • You need to be honest with your sponsor and to illustrate this let me take you to one of many possible areas; the end of project deadline. You need to establish why that deadline has been set and if the deadline looks very tight then be professional and feed this back to your sponsor. However this needs to be couched in project management terms; the link with project risks or the budget seems small for the tight timetable or the skills you need are not available

There is no magic bullet for your first meeting however it will help to do as much preparation as possible.  Research and discussion with colleagues will soon give you a feel for what you need to know.

What is your experience of the first sponsor meeting and what tips would you give to others?

Strategies for Project Sponsorship by Vicki James, Ron Rosenhead and Peter Taylor published by Management Concepts 


Related Posts:
Categories: Blogs

Noelle Webster-Milam Named Tech 25 Winner

SEP Project Management Blog - Wed, 07/20/2016 - 02:55

TechPoint, the growth initiative for Indiana’s tech ecosystem, recognized Indiana’s tech builders with their announcement of the second annual Tech 25 Class of 2016.

Noelle Webster-Milam, Lead Experience Architect at SEP has been named a 2016 winner.

In 2015, TechPoint launched the Tech 25, a prestigious selection of twenty10-five individuals who are critical and exceptional performers helping to grow our community’s tech and tech-enabled companies.

Winners were selected from three main role categories, reinforcing the core roles that building product and building revenue play: 10 in tech product/R&D, 8 in sales/marketing, and 7 in “other.” In addition to being star performers at their companies, winners are committed team players who build others up through mentoring, volunteering and positive example and are committed to contributing to the broader tech community.

“I’m honored to be included in TechPoint’s Tech 25 Class of 2016,” said Webster-Milam. “It’s been so exciting to play an integral part in SEP’s growth from an engineering company to a product design and development company. It’s also been very exciting to see that change make an impact on our client’s work and their continued successes. I’ve learned so much since I’ve started at SEP and I believe it’s the culture, leadership, and my driven peers who push me to be better each and every day.”

The Tech 25 Class of 2016 is as follows:

Product/Software Development (10)

  • Grant Dawson, VP, Information Technology at T2 Systems
  • Brian Deyo, Head of Employee Engagement Research at Bluebridge
  • Andy Falkenstein, Director of Product Management at Geofeedia
  • Ryan Feicok, Manager, Tech Solutions at PAN
  • Tyler Foxworthy, Chief Scientist at DemandJump
  • Adam Gillaspie, Director of Development at PactSafe
  • Corey Kime, Director of Client Experience at
  • Dan Rigsby, Principal Software Architect at Angie’s List
  • Ian Runyon, Director of Solutions at MOBI
  • Noelle Webster-Milam, Lead Experience Architect at SEP


Marketing & Sales (8)

  • Nick Badgett, Senior Director, Global Marketing at Return Path
  • Jill Casey, Marketing Manager at Renaissance Electronic Services
  • Dave Duke, VP Customer Success at Sigstr
  • Kristen Hamerstadt, Director of Marketing at SmarterHQ
  • Michael Moskalick, Sales Manager at Cimcor, Inc
  • Alex Smith, Director of Business Development at SteadyServ Technologies
  • Jessica Stephenson, VP of Marketing & Talent at ExactHire
  • Ashley Walsh, Director of Marketing at Formstack


Other (7)

  • Christian Beck, Principal Design Partner at Innovatemap
  • Samantha Haddad-Foster, Director of Talent at TinderBox
  • John Henry, Manager, Customer Development at Vennli
  • Adam Hoeksema, Director, Loan Programs at Flagship Enterprise Center
  • Josh Knox, Service Delivery Manager at Diverse Tech Services
  • Amy Oviedo, VP People Operations at Kinney Group
  • Steve Pruden, VP of Strategy & Partnerships at Appirio

Webster-Milam has been an integral part of growing SEP’s product design capabilities, including bringing her expertise in user research to client projects.

“As our local Indy design community continues to grow and develop there is still so much more to do and by no means am I stopping here. I’m looking forward to continuing to make more awesome happen at SEP, with our clients, and our Indy design and tech community,” said Webster-Milam.

Full biographies and photos of the Tech 25 Class of 2016 are available on




TechPoint is the nonprofit, industry-led growth initiative for Indiana’s technology companies and overall tech ecosystem. The team is focused on attracting talent, accelerating scale-up companies, activating the community, and amplifying stories of success. For more information, please visit

Categories: Companies

Why you Should Attack Your Systems - Before "They" Do

Building Real Software - Jim Bird - Tue, 07/19/2016 - 22:32

You can't hack and patch your way to a secure system.

You will never be able to find all of the security vulnerabilities and weaknesses in your code and network through scanning, or by paying outsiders to try to hack their way in.

The only way to be secure is to design and build security in from the beginning:

  1. threat modeling and risk assessment when designing apps and networks
  2. understanding and using the security features of your languages and frameworks, and filling in any gaps with secure libraries like Apache Shiro or KeyCzar…
  3. hardening the run-time using guidelines like the CIS benchmarks and tools like Chef and Puppet and UpGuard
  4. carefully reviewing every change that you make to code and configuration before putting them into production
  5. training everybody involved so that they know what to do, and what not to do
This is hard work, and it is unavoidable.

So what's the point of penetration testing? Why do organizations like Intuit and Microsoft have Red Teams attacking their production systems? And why are Facebook and Google and even the US Department of Defense running bug bounty programs, paying outsiders to hack into their system and report bugs?

Because once you've done everything you know how to do - or everything that you think you need to do - to secure your system, the only way to find out whether you've done a good enough job, is to attack your systems - before the bad guys do.

Attacking your system can show you where you are strong, and where you are weak: what you missed, where you made mistakes. It will uncover misunderstandings and hilight gaps in your design, in your defensive controls, and in your logging and monitoring. Watching your system under attack, watching what attackers do and how they do it, understanding what to look for and why, how to identify attacks and how to respond to them, will help change the way that you think and the way that you design and code and set up and run systems.

Let's look at different ways of attacking your system, and what you can learn from them:

Pen Testing

Pen testing - hiring an ethical hacker to scan and explore your application or network to find vulnerabilities and see what they can do with them - is usually done as part of due diligence, before a new system or a major change is rolled out, or once a year to satisfy some kind of regulatory obligation.

Pen testers will scan and test for common vulnerabilities and common mistakes in network and system configuration, missing patches, unsafe default settings. They'll find mistakes in authentication and user set up logic, session management, and access control schemes. They'll look at logs and error messages to find information leaks and bugs in error handling, and they will test for mistakes in some business logic (at least for well-understood workflows like online shopping or online banking), trying to work around approval steps or limit checks.

Pen tests should act as a reality check. If they found problems, a bad guy could too - or already has.

Pen testers won't usually have enough time, or understand your system well enough, to find subtle mistakes, even if they have access to documentation and source code. But anything that they do find in a few days or a few weeks of testing should be taken seriously. These are real, actionable insights into weaknesses in your system – and weaknesses in how you built it. Why didn't you find these problems yourself? How did they get there in the first place? What do you need to change in order to prevent problems like this from happening again?

Some organizations will try to narrow the scope of the pen tests as much as possible, in order to increase their chance of getting a "passing grade" and move on. But this defeats the real point of pen testing. You've gone to the trouble and expense of hiring somebody smart to check your system security. You should take advantage of what they know to find as many problems as possible – and learn as much as you can from them. A good pen tester will explain what they found, how they found it, why it is serious, and what you need to do to fix it.

But pen testing is expensive and doesn't scale. It takes time to find a good pen tester, time to set up and run the test, and time to review and understand and triage the results before you can work on addressing them. In an Agile or DevOps world. where changes are being rolled out every few days or maybe several times a day, a pen test once or twice a year won't cut it.

Red Teaming

If you can afford to have your own pen testing skills in house, you can take another step closer to what it’s like dealing with real world attacks, by running Red Team exercises. Organizations like Microsoft, Intuit and Salesforce have standing Red Teams who continuously attack their systems – live, in production.

Red Teaming is based on military Capture the Flag exercises. The Red Team - a small group of attackers - try to break into the system (without breaking the system), while a Blue Team (developers and operations) tries to catch them and stop them.

The Blue Team may know that an attack is scheduled and what systems will be targeted, but they won't know the details of the attack scenarios. While the Red Team’s success is measured by how many serious problems they find, and how fast they can exploit them, the Blue Team will be measured by MTTD and MTTR: how fast they detected and identified the attack, and how quickly they stopped it or contained and recovered from it.

Like pen testers, the Red Team's job is to find important vulnerabilities, prove that they can be exploited, and help the Blue Team to understand how they found the vulnerabilities, why they are important, and how to fix them properly.

The point of Red Teaming isn't just to find bugs - although you will find good bugs this way, bugs that definitely need to be fixed. The real value of Red Teaming is that you can observe how your system and your Ops team behaves and responds under attack. To learn what an attack looks like, to train your team how to recognize and respond to attacks, and, by exercising regularly, to get better at this.

Over time, as the Blue Team gains experience and improves, as they learn to respond to - and prevent - attacks, the Red Team will be forced to work harder, to look deeper for problems, to be more subtle and creative. As this competition escalates, as both teams push each other, your system - and your security capability - will benefit.

Intuit, for example, runs Red Team exercises the first day of every week (they call this “Red Team Mondays”). The Red Team identifies target systems and builds up their attack plans throughout the week, and publishes their targets internally each Friday. The Blue Teams for those systems will often work over the weekend to prepare, and to find and fix vulnerabilities on their own, to make the Red Team’s job harder. After the Red Team Monday exercises are over, the teams get together to debrief, review the results, and build action plans. And then it starts again.

Bug Bounties

Bug Bounty programs take one more step closer to real world attacks, by enlisting outsiders to hack into your system.

Outside researchers and white hat hackers might not have the insight and familiarity with the system that your own Red Team will. But Bug Bounties will give you access to a large community of people with unique skills, creativity, and time and energy that you can't afford on your own. This is why even organizations like Facebook and Google, who already hire the best engineers available and run strong internal security programs, have had so much success with their Bug Bounty programs.

Like Red Teaming, the rewards and recognition given to researchers drives competition. And like Red Teaming, you need to carefully establish - and enforce - ground rules of conduct. What systems and functions can be attacked, and what can't be. How far testers are allowed to go, where they need to stop, and what evidence they need to provide in order to win their bounties.

You can try to set up and run your own program, following guidelines like the ones that Google has published or you can use a platform like BugCrowd ( or HackerOne ( to manage outside testers.

Automated Attacks

But you don't have to wait until outsiders - or even your own Red Team - attack your system to find security problems. Why not attack the system yourself, every day, or every time that you make a change?

Tools like Gauntlt and BDD-Security can be used to run automated security tests and checks on online applications in Continuous Integration or Continuous Delivery, every time that code is checked in and every time that the system configuration is changed.

Gauntlt ( is an open source testing framework that makes it easy to write security tests in a high-level, English-like language. Because it uses Cucumber under the covers, you can express tests in Gherkin's familiar Given {precondition} When {execute test steps} Then {results should/not be} syntax.

Gauntlt comes with attack adaptors that wrap the details of using security pen testing tools, and sample attack files for checking your SSL configuration using sslyze, testing for SQL injection vulnerabilities using sqlmap or checking the network configuration using nmap, running simple web app attacks using curl, scanning for common vulnerabilities using arachni and dirb and garmr, and checking for serious vulnerabilities like Heartbleed.

BDD-Security ( is another open source security testing framework, also based on Cucumber. It includes SSL checking (again using sslyze), scanning for run-time vulnerabilities using Nessus, and it integrates nicely with Selenium, so that you can add automated tests for authentication and access control, and run web app scans using OWASP ZAP as part of your automated functional testing.

All of these tests can be plugged in to your CI/CD pipelines so that they run automatically, every time that you make a change, as a security smoke test.

You can take a similar approach to attack your network.

Startups such as

provide automated attack platforms which simulate how adversaries probe and penetrate your systems, and report on any weaknesses that they find.

You can automatically schedule and run pre-defined attacks and validation scenarios (or execute your own custom attacks) as often as you want, against all or parts of your network. These platforms scale easily, and provide you with an attacker's view into your systems and their weaknesses. You can see what attacks were tried, what worked, and why. You can use these tools for regular scanning and testing, to see if changes have left your systems vulnerable, to evaluate the effectiveness of a security defense tool, or, like Red Teaming, to exercise your incident response capabilities.

Running automated tests or attack simulations isn't the same as hiring a pen tester or running a Bug Bounty program or having a real Red Team. These tests have to be structured and limited in scope, so that they can be run often and provide consistent results.

But these tools can catch common and serious mistakes quickly - before anybody else does. They will give you confidence as you make changes. And they can be run continuously, so that you can maintain a secure baseline.

Why you need to Attack Yourself

There is a lot to be gained by attacking your systems. You'll find real and important bugs and mistakes - bugs that you know have to be fixed.

You can use the results to measure the effectiveness of your security programs, to see where you need to improve, and whether you are getting better.

And you will learn. You'll learn how to think like an attacker, and how your systems look from an attacker's perspective. You'll learn what to watch for, how to identify an attack, how to respond to attacks and how to contain them. You'll learn how long it takes to do this, and how to do it faster and easier.

You'll end up with a more secure system - and a stronger team.

Categories: Blogs