On this Independence Day weekend we remember the struggles of our forefathers (and mothers), the separation from Britain and the Declaration of Independence that brought it.

Ok, let's be honest...we really spend the days thinking about grilling, fireworks, getting in on the big sales or getting away somewhere interesting. Me, I'll be spending the time off trying out my new inflatable kiddie pool with canopy and sprinkler (I won't actually be in the pool, the kids will of course).

But, on the topic of independence, I’ve recently been reading about the Customer and Project Team’s Bill of Rights in the book ‘Software Project Survival Guide’, by Steve McConnell. He introduces this idea by comparing a poorly run software project to 17th century life under mob rule. This experience can be “solitary, poor, nasty, brutish, and hardly ever short enough.” In order for a software project to survive, all parties need to agree to treat each other in a civilized way. These rules of civilization he summarizes first in the Customer’s Bill of Rights:

CUSTOMER'S BILL OF RIGHTS
I have the right:
1. To set objectives for the project and have them followed
2. To know how long the software project will take and how much it will cost
3. To decide which features are in and which are out of the software
4. To make reasonable changes to requirements throughout the course of the project and to know the costs of making those changes
5. To know the project's status clearly and confidently
6. To be apprised regularly of risks that could affect cost, schedule, or quality, and to be provided with options for addressing potential problems
7. To have ready access to project deliverables throughout the project

But, this is a two-way street. On a software project, customers must pay for their rights by respecting the project team's rights, which he lists below:

PROJECT TEAM’S BILL OF RIGHTS
I have the right:
1. To know the project objectives and to clarify priorities.
2. To know in detail what product I'm supposed to build and to clarify the product definition if it is unclear.
3. To have ready access to the customer, manager, marketer, or other person responsible for making decisions about the software's functionality.
4. To work each phase of the project in a technically responsible way, especially to not be forced to start coding too early in the project.
5. To approve effort and schedule estimates for any work that I will be asked to perform, This includes the right to provide only the kinds of cost and schedule estimates that are theoretically possible at each stage of the project; to take the time needed to create meaningful estimates; and to revise estimates whenever the project's requirements change.
6. To have my project's status reported accurately to customers and upper management.
7. To work in a productive environment free from frequent interruptions and distractions, especially during critical parts of the project.

I would love to see a project kickoff meeting where all parties gather around a large table to read through the Bill of Rights document together and clients, managers, senior management, project team all take their turn to sign the document. This will affirm their commitment to upholding their responsibilities (although it seems to be mainly the responsibility of the project manager to make sure all of these rights are upheld). Who knows, maybe some project teams out there go through that exact process, or maybe this could be included as a part of the project charter. It’s an interesting idea, but at the very basic level I agree with the author that everything listed here is extremely important for the happiness of the client and project team, and the health and success of the project. I hope to find a way to incorporate this into my projects going forward, so if you’re my client or on my team, better keep a quill handy!

We just recently completed the launch of a feature rich and highly complex calendar system for our largest client, United Jewish Communities. The project accomplished a number of technical and functional goals, and was also our largest of the year (well, it was the largest project for my client and since I only pay attention to what my client does, it might have actually been the largest of the year).  But, this post is not specifically about the project, but the new processes we introduced into this project lifecycle that I think have proven extremely beneficial to project team, client and end users.

Functionality Review Sessions – In an effort to improve our quality assurance and involve more of our QA team before the development completes and moves onto the testing site, we held functionality review meetings that involved the Project Manager (me), the Director of Technology, the programming team and a member of the QA team. This was in addition to the regular status meetings, and the goal of these meetings was to review the functionality developed to date and confirm that it met the requirements and worked properly with the other parts of the system. Each programmer would demonstrate what he/she had worked on and issues would be detected early at a stage when they would be more easily corrected.

This idea of the cost of early vs. late detection is demonstrated very well by this graph created by Contrux software.

(More on this concept in another post).

BETA Sites & Launch – About a month before the launch to the live websites, we went into BETA mode (not new to many in the software world, but something our group has wanted to do for a while). We created mirror versions of the 160+ websites that are using our CMS and calendar, and gave them a place where they could try out the new functionality and view their events in the new calendar system. This accomplished two goals:

• It gave the users time to become comfortable with the new system before it was ‘thrown’ upon them. One of the most challenging things about the tool that we develop for United Jewish Communities is that it needs to be user friendly to both the tech savvy and the tech un-savvy at the same time. In our last large release, there was criticism from the field that we did not give the users an opportunity to try out the new system before it was thrust upon them. We took that criticism seriously and wanted to make some changes.
  
  
• It opened up the new work to several hundred more pairs of eyes, giving us and them more of an ability to catch defects that could be specific to one website or one specific arrangement, system, etc.

Training – we also conducted web & phone training sessions for over one hundred users, spread out over 8 sessions. The users were able to train on their own BETA sites and could ask questions early and address any concerns before the launch to the live sites took place. This was also a great forum to share ideas about how to make best use of the new calendar functionality.

All of this did a great deal to improve our quality assurance and control processes and the client and end-user acceptance of the product.

Did the project launch 100% bug-free?

Not exactly. I mean, let’s be realistic here. This is the world of software after all.

Did we have any real show-stopping issues when we launched, either delaying the launch or making for rough sailing for the post launch days and weeks?

Not really. There have been bugs that both our team and the end users have found since launch that were not detected before, but we have been handling them carefully and efficiently and the system has remained stable throughout this process.

Do we have happy customers?

I think so, there seems to be a good feeling in general and we're starting to see some nice creative use of the new system and good ideas going around for how to make the best of the new tool.

I’m happy and relieved that the project has launched and completed smoothly, and excited about the progress that was made both technologically and in various project management process areas. I look forward to continuing to incorporate these processes and finding new ones that will make future projects even more successful.

I don't exactly have a corner office. We just recently moved to a new space and I sit at a window along a row of desks at the western side of the room. Our arrangement along the western side is nice and intimate, and I have the pleasure of being just a couple feet away from a very nice woman who is also our most senior salesperson. Because we sit so close to each other, I've also had the opportunity of listening in on some of her sales calls. This has been both entertaining, exciting, and sometimes totally frightening. Just last week I overheard a call with a potential new client and was not only glad I was sitting down, but happy my lunch had already digested. Here's why:

She said (not exact quotes, but hopefully enough to get the idea), "Yes, we can definitely set you up with a new website, we just completed a project for another client in the same field as yours, took about 8 weeks to turn around so will probably be the same for you."

I cringed, and I thought "What??! How can we make any estimate of schedule when we have absolutely no idea what the project will entail or what technologies we will be using, what specific needs they will have, etc. We aren't even approaching the beginning of the Cone of Uncertainty, so to make any kind of estimate at this stage is complete project suicide!"

Then she said, "We used a new Content Management System (CMS) to integrate the content of our other client's old site to new, and I'm sure we'll be able to help you in the same way."

I glared at her and almost grabbed the phone out of her hand, and thought "Wait!! We don't know enough to make a commitment to this person about using a new CMS for their site! There are still too many unknowns and a good deal of risk associated with using this technology. The best we can do is offer to research the idea and go back to them with an analysis of the benefits and risks of venturing into the project with this new CMS, and make sure it's clear with the impact on schedule and budget would be if we hit any complications."

Then she said "I understand that you're on a tight schedule, we'll corral our people and make sure we can get this out the door by August 1"

My heart skipped a beat as I thought, "How can you make any promises of schedule when you don't know what the availability of our resources are, people's vacation schedules, our key production person is out this week, etc."

Then I realized why I'm not a salesperson. A salesperson has to be a "can do" person all of the time, because she is going to bring in our next deal and she's going to make sure there's plenty of dollars around for my next bonus (that's just a hint there for someone, you know who you are). So, it's her job to raise the energy level and get this potential new client excited about the prospect of working with us, whatever that might mean. And, she's good at it, too. She's brought in a lot of new projects in her time here.

As a project manager, it's my job to make sure the new work that's brought in is done well, on schedule, within budget, and meets the client's needs. Is it possible to reach all of those goals in every project? That's the subject of many other posts, but it's definitely the goal we strive for at Flightpath. But, a project manager also sometimes needs to be a "can't do" person. A PM needs to be a leader and keep the team energized, organized and informed, but also attuned to the reality of the tasks we are undertaking and the risks involved, the uncertainties at each stage of the project and it's affect on schedule, etc. When a project is done well and the client is happy, the saleswoman's job is easier because the client will ask us to do more work.

So, for a minute I imagine what the sales call might go like if I was doing the pitch:

"Well, we did do a somewhat similar project in the past with another client, but without taking a closer look at your site and the technologies that run it, I couldn't even make a ballpark estimate of time that it would take to complete the project. Let me call a meeting with our programmers and look through your site and we'll get back to you in a few days."

"click!"

Ok, so I don't think we're going to get that deal.

The reality is that many times we are challenged with urgent scheduling demands, new technologies that we might not be familiar with or uncertainties of scope, details, etc. The advantage of being at smaller company is that it's possible to shift resources around to get the work done, even when some of the details don't get ironed out until later on. Working with a new technology can be a daunting task sometimes, but can also be very exciting and challenging, and bring us higher up on the escalator of risk.

So, I'm going to continue to do my job and she will continue to do hers. I'll continue to be entertained by her sales calls and know that together we'll keep things busy at Flightpath.

Picture it:
It’s a perfectly fine morning, and you’re on your way to work. You’ve beaten the odds in your daily challenge of toddler managing and gotten out of the house in under the estimated 40 minutes, and now you’re heading to the subway. You get to the station, only to find out that “due to necessary maintenance work, the train will be rerouted through Queens….” Anyone who has gone through this and hasn’t cursed under their breath must have the patience of a saint.

More on subways…for the last few weeks the escalator at the subway stop nearest my daughter’s preschool has been out for maintenance work. This must be one of the deeper underground subway stops in New York City, because without that escalator there are 50 (yes, we’ve counted them) steps we climb before we can even get to the turnstile. Then there’s another 27 before we get to the street. I should be grateful for the extra exercise, but with a space cadet three-year-old who likes to twirl and jump around the steps, my trip up those extra 50 can sometimes be a harrowing experience.

Then I started reading the book titled “To Engineer is Human, The Role of Failure in Successful Design”, by Henry Petroski, and it helped me get a different perspective on those things that seem like annoying hassles of everyday life. The book discusses the tragedies and near-tragedies of bridges, towers, and airplanes that have been poorly designed or maintained. Sometimes the failure is caused by designers trying too hard to have the most lightweight and graceful structure, the Tacoma Narrows Bridge is a perfect example that probably anyone who’s taken a high school physics course is familiar with.

Sometimes the failure is due to engineers & construction crew deciding that the elements of the original design are too difficult to construct to exact specifications and decide to take some short cuts, as in the  Kansas City Hyatt Regency Hotel Skywalks collapse in 1981.

In other cases the failure is due to crucial elements in the structure malfunctioning under extreme weather conditions, the horrible disaster of the Challenger Space shuttle in 1986 is an unfortunate example. 

Structural failure can also come from fatigue, from a crucial element of the tower, bridge, plane, subway car or escalator that has suffered enough fatigue and can no longer perform to its specifications. But these accidents can be prevented by routine maintenance, close checking of all critical elements to ensure that they can perform properly. The maintenance work being done on the train we’re taking or the escalator we wanted to ride is going to help ensure that we will be able to continue to ride safely and comfortably in the future. It’s not something that’s easy to accept when your commute is doubled, but better to be safe than sorry.

So, how does this relate to website applications and web servers? It’s definitely possible for programmers, designers, quality control (and yes even project managers) to take shortcuts, which can sometimes result in failure of an application or website. Taking on a risky project without being fully prepared for those risks can also sometimes result in failure. Or, subjecting your system to conditions that it wasn’t designed for can cause failure. Of course, failure in web servers and web applications is nowhere near as tragic as failure of a bridge or the space shuttle (but of course with computers controlling so much of our lives these days, the calculations made by computers can sometimes have a direct impact on structural success or failure).

What about fatigue? Do websites and web servers suffer from fatigue in the same way a bridge, plane or tower can? Well, maybe not exactly the same, it seems unlikely that a web server will have a crack or a tear in its outer casing that will cause failure of the system (although, lose connections between cables, network cards, etc. can definitely cause instability). Web servers need to be rebooted, patched and monitored to ensure that all critical systems are operating properly. Web Applications need to be scaled or redesigned when the demands on the application grow beyond what was originally planned for. Can this be a hassle to the people who use those systems? Of course! Nobody likes their website going down for system maintenance, e-mail unavailable, etc. We rely so much on the internet that once it’s taken away our productivity is at a stand still. This is a necessary fact of life of using technology and we should all remind ourselves that it’s better that the proactive maintenance is done and potential issues resolved early before they become bigger problems.

The book doesn’t only talk about failures. It also details amazing successes of structural design, and discusses how many engineering successes come from learning from the mistakes of the past. We need to follow this same practice in the software world, to accept and learn from the failures of the past and use them to build our new successes, and make sure that the health of our websites and servers are among our top priorities.

Early in a project, so many of the specific details of the nature of the software being built, specific requirements, project plan and staffing details are all very unclear. Because there are so many variables early on in the project, it is crucial to include a large degree of uncertainty or variability in the project estimate. This is not about being purposely misleading or avoiding commitment to an exact number with your stakeholders, this is about accepting the reality of software projects that leave so much to be defined early on. To commit to an exact number at the very beginning would be misleading yourself and your stakeholders and presenting a false sense of confidence in something that still has so much yet to be defined.

Steve McConnell, CEO and Chief Software Engineer at Construx Software, presents the idea of a “Cone of Uncertainty” in his book “Software Estimation: Demystifying the Black Art (2006)”.

The horizontal axis shows significant project milestones. The vertical axis shows the degree of error that has been found in estimates created by skilled estimators at various points in the project. What is obvious from the diagram is that estimates created early on in the project are subject to a high degree of error (from .25x lower to 4x higher). As the details of the project become defined and understood, the cone narrows. Obviously the most accurate estimate is made at the very end of the project development, but the challenge in the software world is to find somewhere in between where we know enough about the project to make the best estimate possible while still allowing major stakeholders to plan financially. More about the Cone of Uncertainty, and other estimation resources can be found here:
http://www.construx.com/Page.aspx?hid=1648

In his book Steve McConnell explains several different techniques used in making software estimates. He also made a very interesting and entertaining blog post recently, where he shared similarities between building a fort in his backyard and problems people run into with software estimates. The general idea here, and very humorously explained, is that in the beginning of a project it’s easy for us to assume that everything will go as planned and the project will proceed smoothly and in a timely manner, but it’s very common for things to take longer than expected. In his case, it was the little construction project in his backyard.

I haven’t built any forts lately, but I’ve managed many projects at Flightpath, and some that have taken longer than the original estimate, for one reason or another. But I also see this concept clearly illustrated in my day to day life outside of Flightpath. I find that it’s almost impossible to make any type of time or schedule commitment when a toddler is involved. I’m fortunate to be the mother (or project manager) of two little girls, and have the pleasure of bringing the older one to preschool every morning. What should take only 15 minutes, can sometimes take up to 40…and this is why:

1. The 2nd and 3rd bowl of cereal (6 mins)
2. Trip to the potty before leaving home, which can sometimes include the mandatory reading of the Dr. Seuss book while waiting for the potty business to complete. (8 mins)
3. Sneakers that get taken off and put back on again, only to get taken off one more time (and of course put back on again) before the final trip out the door. (2 mins)
4. Unexpected meltdown about which jacket to wear, and wanting to wear rain boots and bring umbrella on a perfectly sunny day. (6 mins)

You catch my drift…

So, I’m learning more about how to properly include uncertainty in my estimates at the appropriate times in the project development, both in the projects I manage at Flightpath and the mini-projects I manage at home every morning. It’s a good thing that our preschool allows us a 30 minute window for morning dropping off!

I just finished a great book, titled Waltzing with Bears, Managing Risk on Software Projects by Tom DeMarco and Timothy Lister. Risk is something we all deal with in our day to day lives, and probably don’t deal with enough in our professional work. The authors open with the idea that if a project doesn’t have any risk to it, it’s just not worth taking. This notion is especially applicable to the interactive design field that Flightpath is in.

The authors share the analogy presented by risk management expert Bob Charette, who proposes imagining your company and its competitors as a set of down escalators.

“You are obliged to climb up the escalator, which is moving against you. And your competitors are doing the same thing on theirs. The faster their stairs move, the faster everyone has to climb to stay even. If you pause, even for a moment, you begin to fall behind. And, of course, if you pause for too long, you will drop off the bottom, no longer able to compete…

Competitors get to enter their escalators halfway up. Falling behind, then, guarantees that the new competition will enter above you.

At the top of each escalator is a level that will allow you to control the speed of not just your escalator, but of everyone else’s as well. If you’re the first to reach the lever, that shows that you’re a better climber than your competitors. So, you can speed up all the stairs so that you can stay even but your competitors can not.

…This is an era in which risk-taking is rewarded, leaving companies that run away from risk as a plunder to be divided up by the others.”

But taking on the most innovative and thus risky projects is not all about being the sexiest agency out there; risks have to be managed. To take on a risky project without a formal plan in place to manage those risks is taking a major gamble with your project, your stakeholders, and maybe even your career.

The book states that risk management is like project management for adults. Something which adults have that children don’t is a willingness to confront the unpleasantness in life, from the little annoying things to the cataclysmic (examples such as putting a band-aid on a cut to keep it from getting infected, or taking out life or home-owners insurance policy as protection against the bigger challenges). Taking note of bad things that can happen and planning for them accordingly is a mark of maturity.

What can you do to make your project sexy (and of course risky) at the same time? Examples are trying out a new technology, working with a third party application that does some incredibly cool stuff, or doing something that nobody else out there has done before. Then there are the core risks that any project (no matter how un-sexy) can have, the book lists these five core project risks:

- schedule flaw, interruption
- scope creep
- turnover
- specification breakdown
- under-performance

To ignore any of these is as disservice to your project team, your stakeholders, and yourself.

But risk discovery and planning can be an unpopular task and can make the risk identifier look like a ‘can’t-do’ person or a whiner. Risk management makes a limited amount of can’t-do thinking okay. It’s better to raise the issues early on and be prepared for them if and when they come, then to ignore them entirely.

So, I’m ready to become more of a can’t-do person, and ready to be more prepared for anything good or bad that will come my way. I hope that you’ll join me, and I’ll see you on the escalator!

Back in the day, our general modus operandi was to listen to a client or prospect's wishes and try and deliver a product that met their goals and expectations.  All well and good, but apart from delivering a good-looking, usable web site, we weren't necessarily adding a lot of value.

Nowadays, we try and approach our client engagements asking questions about how we can really provide value and drive business for our customers.  We do our best to use our seasoned,  strategic knowledge of best practices for web design and development to make client sites as successful as possible.  Hopefully, this site, will meet those same kinds of goals for us. 

They may sound like no-brainers in 2008, but this time around, we started with copy, site structure, meta data, and page titles that would be optimal for search.  We integrated Google Analytics for traffic metrics and routed our email sign-up form directly through to Exact Target (our email service provider) via their API.  We utilized open source software (like blogengine.net) to streamline our development process and deliver a best-of-breed feature set. We even shot some video on a shoestring to help get our points across.  Together, each of these steps should contribute to getting the Flightpath message out to the right people as effectively as possible.

I'd like to congratulate all the members of our staff that did such a great job contributing to this web site and welcome anyone who's reading this to Flightpath's new blog.  I hope you'll check back with us regularly and see what we're up to and what we're talking about.

- Jon Fox