Probably the most difficult situation is the latter — a boss that’s too hands-on, or perhaps an external resource that is too busy, yet absolutely must approve every decision. The story usually goes something like this: He’s a great guy, pretty easy to get along with when it comes right down to it — but he’s also insufferably “hands-on.” He’s just got to review every critical decision, contributing, fine-tuning and tweaking until it’s just right. This micro-managing mentality is causing all kinds of bottlenecks: Decisions are held until the last moment, changes are made late in the game, and your entire department suffers — staying late to “catch up” after your boss delivers his final word on any given issue. But here’s the real kicker: He’s good at what he does, and even though it creates internal chaos the finished product is that much better for his input.

Consider the image to the right: A critical “quality spike” representing the single project resource that is overloaded. This resource does raise project quality, but the spike also represents a huge bottleneck to the project.

Your department has tried everything: Getting him involved earlier in the game (it doesn’t work, his schedule is booked and it always presses to the last moment); Involving other review sources so your boss’ input is minimized (that helped a bit, but the other sources don’t like it when your boss overrides their contribution); You tried publishing the “departmental cost” figures that show all this inefficiency (but the powers-that-be seem to feel this is “just the cost of doing business”).

This is not a simple problem. It gets right to the root of the dynamics created in working teams. How can the situation be improved, realizing positive gains in a habitually entrenched process that some recognize as painful, but overall is regarded as good enough?

There are really two issues that need to be dealt with here. One is obvious, one perhaps a little bit less so. Most strategies up until now have focused chiefly on the primary goal:

“How can we minimize the negative impact of a critical resource (our ‘hands-on boss,’ for example) that doesn’t work efficiently with your team?”

The problem with this approach is that it attacks an entrenched problem head-on, and often does so using a single head-on approach to solve the problem. When an attempt fails, that approach is discarded and another tried. The principle flaw here is that each attempt to solve the problem is, in and of itself, not effective enough to get the job done. A secondary flaw is that each separate attempt tends to get lost in the chaff of day-to-day operations. We all know there’s a problem, but nobody is really tasked with studying it, compiling the entire scope of the problem and its impact, and somehow bringing about a solution.

For example, when your department produced some figures on costs to the organization, those figures clearly showed that, through inefficiency, rework, and last-minute changes, your team suffered. You even went so far as to tie it to actuals, a dollar figure that represented all that overtime and rework — but, it was accepted as “the cost of doing business.” Since it didn’t work, it was discarded — but the fact is, it’s only part of the overall puzzle.

So the head-on solution won’t work. Let’s consider a more subtle approach to the problem:

“How can we make the critical resource less critical?”

This would achieve the same result, but it’s really an entirely different problem — one that can be attacked somewhat obliquely. Rather than focusing on how to change the way your boss works (aka “the critical resource”), try focusing on changing what your boss needs to work on.

The first step toward a solution is realizing that solving this problem is a project, just like any other. It needs a project lead and sponsor. It needs to be handled as an iterative project, and the team needs to recognize that incremental improvement toward an ideal is acceptable. You aren’t going to discover a single silver bullet that solves the whole problem — that’s just not the nature of human team dynamics.

Make it a project initiative

Once your “quality improvement project” is up and running it will snowball. Here are a few steps that will get the ball rolling:

1. Initiate the project. Don’t think of this as a “workplace problem” that needs to be fixed in the short term. Instead, create a project initiative around it and get some mindshare going. Someone is going to need to lead the project, even if it’s unofficial — that person will keep the forward momentum.
2. Focus on making many small improvements across the board. For example, in the case I described above, consider how involving other review sources did in fact help, but not always. That’s an incremental improvement, and it raised the quality of the project a little bit.

Now, consider the impact of this approach over time. If numerous improvements can be implemented, and each one raises project quality just a little bit, it has an inevitable outcome: Your boss is going to have less to worry about, and less to be involved in. This is shown visually in the second image — as the overall quality matrix delivers improvement across the project, the “critical spike” that represents your boss’ workload begins to shrink. This is a quality matrix at work.

The goal is simply this: Dilute the need for your boss to be involved in every decision, by raising the bar in as many places as possible. You will gain a “double whammy” by not only reducing the amount of work he needs to contribute to, but also by increasing his own efficiency since he’ll have less to worry about. The bottleneck will begin to dissipate.

Assemble your team

Get involvement from everyone that’s affected by the problem — your team, your peers, other departments that might be affected. Of course, part of the finesse in this kind of project is to make it clear exactly what problem you are solving without making the project sound subversive or offending the wrong people. Your boss may be a terrible bottleneck, but also remember how valuable he or she is — this isn’t about cutting him out of the picture, going around him, or changing policies you don’t like. It’s much better to focus on things like qualitative improvement, streamlining projects to avoid inefficiency, or developing lean principles. Make it positive, in other words.

Identify key risks

Your probably already know what the main pain points are. Your team experiences them all the time: Loss of productivity, overtime, last minute changes, introducing new errors, reworking something that could already be finished. These are the lesser symptoms of an endemic problem: What are the potential risks if the problem goes unaddressed? Certainly continued loss of efficiency, higher expenses to the company and lower employee satisfaction come to mind. Perhaps there’s even a trend of some team members transferring out of the department to find a better working environment. More dramatic effects can include missed product deadlines, problems with released products or lowered perception of the department’s attention to quality. All of these can have a real financial impact on the company.

Identify those risks that are most significant. Those should become the focal point for initial improvement. This is a “risk driven” model, where high risk is identified — in other words, the most painful or potentially painful result of the problem gets the most attention as early as possible. Generally it’s best to tackle a few things at a time. While the list of risks could be very long, if you try to solve every problem at once it’s going to be overwhelming.

Mitigate

Once you’ve identified the top few risks, pull together your project team and identify candidate solutions. You’re designing something new here, so it’s going to seem like brainstorming — which is exactly what it is:

1. Can more attention from outside experts improve the overall product, lowering your boss’ need to be involved?
2. Would the quality assurance organization be a helpful partner in achieving this?
3. Could changes in the project timeline better accommodate your boss’ hectic schedule? Perhaps driving for earlier involvement (or longer project schedules) would help.
4. Can the team multitask, effectively putting several critical paths into play so that if one gets stalled waiting for your boss, the others move forward?
5. Would better tracking systems and information management help solve the problem? Perhaps your boss would benefit from a system that brings more organization and immediate answers directly to him.
6. Perhaps greater visibility into the project timeline and reasonable deadlines would both improve responsiveness and provide some firm schedule guidance.
7. Information radiators (such as task boards, timelines and assignment lists) might help keep people up to speed on overall project status (and what has moved from “medium” to “high” priority).
8. A widely accessible system that assigns tasks and prioritizes those tasks would increase visibility of current goals as well as get everyone united about what needs attention first.

Every organization is going to discover different solutions that help its specific situation. It will likely take time to hit on the first few steps that move in a positive direction — but those are the ones you want to hang on to.

Include a quality improvement element

Organizations that have the benefit of a formal quality assurance and improvement group should try to leverage the group’s knowledge. Quality assurance is about auditing and measuring progress toward improvement. Most quality assurance groups tend to be very good at measuring improvement over time, and putting that knowledge to use will help in gathering metrics and identifying what’s working, and what isn’t.

Track your progress

Measure, act, measure again, and adjust. This is the heart of most agile development methodologies — and most scientific methods.

The most important thing to do is realize when improvement has taken place. That means tracking information — metrics — about your organization’s efficiency. This can seem pretty amorphous when dealing with a problem such as this. Remember that it comes down to improved efficiency of individuals. Some teams will have simple metrics that are easy enough to track, such as number of projects completed on a monthly or quarterly basis, or number of cases filed. When all else fails, the number of hours committed to rework is a great metric, because it tracks directly to risk identification and mitigation up front. That is, if you properly identify a risk and mitigate it early in the project, the amount of time spent in rework related to that risk goes down.

This is one reason it’s important to have everyone affected by the problem involved: It’s going to require everyone to look for these signs of improvement. It might even require tracking hours spent in rework. Fortunately, with the goal in sight (less time spent reworking and fewer overtime hours) it shouldn’t be too hard to commit people to some moderate tracking.

Gather metrics on what works and what doesn’t work. Emphasize incremental improvement as a desired outcome: Track the results of each effort, and keep the best practices. The important thing here is to demonstrate improvement over time, so that everyone sees each action as contributing to the solution, not as a failure in delivering the end result.

One of the most important goals in creating a project mentality is the positive group effect. Seeing each practice as part of a solution keeps it alive — as opposed to trying something and perceiving failure. As the team, department or company works together to deliver a solution it becomes a self-reinforcing effect. Even your boss might notice, and actively start to take part.

Related posts:

1. Quality assurance as a way of life
2. Exposing the enterprise to risk: Who decides what not to test?
3. Why heroes are bad

One such tool is comindwork.com, a fabulously rich project management software as a service (SaaS) site. While not right for everyone or for every situation it’s definitely worth taking a look at.

Comindwork combines over 250 project management related capabilities under one roof, yet does it with a web interface that is, by and large, a breeze to use. Some of the strengths of the service include traditional project management tools, knowledge management, collaboration tools, information sharing and versioning, and both agile and traditional waterfall management tools (e.g.: think Gantt).

The entry point is easy, and that’s another strength for comindwork: A small team can get started for somewhere around $20 a month (for teams of 10 or fewer, it’s $1 per day that you actually use the service — if nobody logs in, it’s no charge). This offers up a wealth of really advanced tools at a fraction of the cost of most large scale management infrastructure. For companies that don’t have a system in place, it’s easy to give comindwork a spin.

Here are a few of the things I like about comindwork.

It all starts with the personal dashboard. I’m a huge believer in personal (meaning, customized and personally relevant) dashboards, especially if they follow the basic principle of “Getting Things Done” methodologies. Distraction is bad, focus is good:

With the project dashboard, you can:

1. Get a bird-view on all activities where you are involved, see who changed what and when
2. See your nearest milestones
3. Check team members’ status and mood
4. Easily access detailed project-specific dashboards

It offers both traditional (meaning, typically, “large scale”) project management and agile management philosophies living under one roof. At first glance I was taken aback by any system that can claim to offer this mix of tools, but comindwork manages to pull it off. On the traditional side, there are Gantt charts and round-trip import and export of Microsoft Project files, not to mention a whole host of reporting capabilities. On the agile end of the spectrum, to-do lists, tasks and very easy time tracking support simple progress monitoring. Unfortunately, burndown charts have yet to make an appearance, although there’s enough information available that they may not be entirely necessary.

Knowledge management and collaboration are central to the product. Blogs, to-do lists, milestones and business wiki support which codify and share tacit knowledge are tightly integrated into the project. In fact, one of comindwork’s strengths is that so many services are so tightly integrated. For example, linked business wiki entries, tasks and time commitments can be shared and kept up-to-date, with progress being reflected in round-trip Gantt tracking in Project. Notifications of all activity take place automatically, sending out instant email messages or daily digests that summarize project activity.

One of the problems I’ve run into with customers that have no pre-existing system is simply keeping track of all the project artifacts and versions of each. With email flying everywhere, documents being authored, and half the team not knowing how to use source management repositories, how can you hope to keep track of every artifact the team produces? I like to implement a policy of “email doesn’t exist,” but this means you need a tool that’s going to support the policy.

In other words, if someone wants to get something done, it should be in a system, not flying around in email. The idea of half a dozen versions of a document living on everyone’s desktop is just unacceptable to me. Comindwork provides file versioning and drag-and-drop upload. This makes it possible to implement the “email doesn’t exist” policy, and comindwork does a great job of delivering an easy to use tool:

Having a convenient and ubiquitous place to store project artifacts makes it easy for the team to share, manage, and collaborate. Comindwork put enough effort into the interface that it’s not painful:

1. Create a convenient tree-structure of your documents
2. Make common actions on a set of files (mass-delete, mass-move)
3. Provide comments to any file version
4. Versions are stored automatically whenever you upload a file with the same name. Check all revisions and easily revert if required
5. Use drag & drop area for native multiple files upload

You can even email files directly to a folder in your comindwork project.

For more demanding projects, you can design custom workflows to support the security, policies and customer demands of the project. This is an essential tool in my mind. Any project management solution needs to be able to grow with the project. Custom workflow makes it possible:

You can create graphical representation of your business process, modify the process with appropriate business rules and make sure your project is enforcing necessary policy:

1. Define, control and track states and transitions in your business process
2. Encourage process automation and standardization
3. Break your business process into easy to follow step-by-step workflow diagram
4. Reconfigure your business process as needed
5. Clearly define your business process and avoid miscommunication and inconsistency

If you’ve been casting about looking for how to get project tracking off the ground, take the quick tour and see what you think. It’s not a panacea that will fit all project’s needs, but it is a very solid tool that’s been seeing a lot of success lately.

If you decide it’s not for you, take a look at Atlassian’s JIRA too. JIRA is by far my favorite project management tool, especially if you’re agile-oriented. It requires a bit more of an up-front investment to get off the ground (both in terms of deployment and financial cost), but in my opinion, it’s one of very few first-rate tools available today. I’ve been trying to finish a detailed article on JIRA for some time now, so check back in a bit.

Related posts:

1. Fix your boss (or, reduce risk to quality using a matrix approach)
2. Why Agile isn’t enough (and why it doesn’t work)
3. Whole teams

“The problem is that, especially in a small shop, we:

a) Don’t have comparable projects that can be used to provide historical data, especially for partner projects that are often more one-off than core product development. I can say with some confidence how long it takes to add a new Struts 2 action and mapping – that part is easy, but what about the elements on the page? What about the logic?

b) Don’t have the infrastructure in place to really record time spent on any one task, and often find that if we did, it would be inaccurate because we wear so many hats, each hat being taken on and off randomly throughout the day/week.

c) Can’t afford just yet to spend a lot of time making exhaustive estimates, because that’s time that won’t be spent in construction and testing.”

This is probably the most common problem facing software teams today and, quite simply, the root cause of most project failures. Even projects that are regarded as ultimately successful suffer from this issue, as evidenced by frequent project overruns, software delays and adjusted delivery goals. And yet, we have the tools at hand to solve the problem: Function Point Analysis, Proxy-Based Estimating, Evidence-Based Scheduling, and similar tools offer the basic software estimation processes needed to accurately predict the overall cost of a project.

The problem is not with lack of process: It’s with lack of proper adoption. As Kirk points out, in his own situation a host of pressures prevent dedicating the necessary effort, time and resources to do the job right. Put bluntly, relatively unseasoned teams often lack the experience and wherewithal to set up the right processes and make the right investments. These “investments” typically translate into very real costs to the business, longer development schedules being among the most obvious. The pressure applied by a business to set a delivery date now, before enough data has been gathered, can be daunting. It often takes a combination of two things to successfully pull off software cost estimation: First, a team that has the ability to make accurate statements regarding a software project, and second, a business that is willing to listen to that team.

An experienced team

During my years performing project auditing I’ve noticed a trend throughout Silicon Valley, particularly among startup companies. This trend involves creating teams from remarkably bright individuals that have very little formal training or experience in software development. Other sectors, including large scale enterprise and the military, take a different approach: Assembling teams that have the senior leadership necessary to create an effective team. This means a formal understanding of development process as well as experience — because, quite simply, technical knowledge without experience generally results in missteps. Those experienced, senior dinosaurs are actually quite valuable in providing guidance and mentoring to the development team as a whole. But, again being quite blunt, these senior experts (SME’s or Subject Matter Experts) support their teams in a very effective way by providing the voice of experience and authority to the business. This is the bit about “standing up to the business,” and is critical when the business tries to step in and force decisions that just shouldn’t be made yet.

A listening business

Perhaps equally important as building a team with experienced, authoritative leadership is having a business that recognizes the value — and expertise — of its team. That has to extend to a willingness to listen to the team, and take the team’s recommendations at face value. I’ve personally walked away from more jobs than I’ve taken where it was apparent that the business believed in a purely “top down” management style, not giving the team the resources or time it needed to make the right decisions to deliver a quality software product.

Let’s make this concrete: What does “listening to the team” mean? More than anything it means listening to the needs of the team and addressing them. Kirk points out that they have a lack of expertise in software cost estimation: Hire a consultant to work with the team for three to six months to address this need. He points out a lack of infrastructure: Buy the right tools and give the team time to put them in place (they aren’t that expensive). Most appalling to me, he points out a lack of time to invest in estimation because that means the team isn’t coding: Give them the time to do their job right. The long term benefits will be realized ten-fold through accurate software estimation, greater reproducibility and improved software quality (you know how the software is always late or ships with too many bugs in it? This is the root cause).

Strategies for success

For projects that don’t have a body of work product to use for historical data, look outside the project. Unless the team consists of entirely junior programmers with no experience under their belt this won’t be hard to do (the formal nomenclature for this is wideband delphi, an easy-to-use and surprisingly accurate method for discovering historical data where none seemed to exist). The basic process is simple: A moderator and an estimation team with three to seven members is selected for two meetings run by the moderator. In the first meeting the estimation team creates a work breakdown structure (WBS) and discusses assumptions. After the meeting, each team member creates an effort estimate for each task. The second meeting is the estimation session, in which the team revises the estimates as a group and achieves consensus. I’ve had excellent success using this process as a basis for arriving at reasonably reliable estimates, but it’s important to add one more step: Make sure that the programmer that takes up the given task agrees with the estimate, and understands the task in full. Sometimes the group estimate will be more aggressive than an inexperienced programmer is willing to take on; likewise, sometimes an experienced programmer will know it can be done more quickly. Be conservative, and defer to the individual programmer when appropriate.

In regard to making time for the underlying effort in software cost estimation, one of the most common excuses I hear is “we don’t have the tools to record time, our team wouldn’t agree to it, and if we did, it would be inaccurate because we wear so many hats.” Frankly, this is just procrastination. First of all, read Joel Spolsky’s article on Evidence Based Scheduling. It’s an excellent introduction that clearly explains why wearing a lot of different hats, being distracted by unplanned tasks, and having a chaotic environment just doesn’t matter. A good system for measuring velocity is going to understand and accommodate those realities — in fact, the entire purpose for estimating velocity is because of all these unexpected, unplanned interruptions. If we had none, our estimates would be perfect, wouldn’t they? So, where does this excuse lead you but down the same, inevitable path: Lots of misunderstandings with the business, failed deliveries, slipped ship dates, poor software quality and an awful lot of late nights trying to get incomplete software out the door. Stop the addiction: Do the right thing and spend $200 on FogBugz or, if you want to go industrial choose my favorite, Atlassian JIRA (it’ll cost you a couple thousand dollars, but it’s probably the best investment your department will make, period). If you’re looking into JIRA, check out the Greenhopper plugin.

And finally, if you feel you just can’t take the time to estimate and manage your project, keep in mind this is the same as saying “we just can’t take the time to do it right — so we’ll hope for the best.” This is a classical problem for many Agile organizations that focus entirely on the short-term while sacrificing long-term strategy. It’s a situation that leads to a perpetual, self-feeding problem, and it gets worse not better. It’s time to break the pattern and make the decision to fix it.

Probably the most important piece of advice I offer team managers is simply this: “I don’t know” is OK. The worst thing you can do is commit too early. When the business challenges you for a timeline and presses for a hard and fast ship date, the best thing you can say is “I don’t know.” The natural follow on question is going to be “fine, what do you need to find the answer?” Stand firm and insist that you need the time, tools and resources to accurately estimate the job. Cite past performance — or past lack of performance, failed deliveries and customer service problems, if need be. Ask the business “do you want more of the same, or do you want to improve?” Ultimately, it’s up to you as the team lead, Scrum Master or project manager to make this happen.

No related posts.

I respect goals more than most people — having founded or directed a number of innovative projects that’s probably a given. But I also respect a balanced strategy in developing those goals and the forethought to plan for changes.

I decided to take on a project reinventing a product that had over a decade of history behind it. Actually, I was more talked into taking the project by a friend and prior colleague. Over many months we went back and forth on the subject — but eventually I caved and decided to do it. In hindsight, my mistake was obvious. I had let my friend sway me, despite all the cynical bias I usually apply to potential projects.

When I started discussing taking the project on, the terms had already been set in stone. An early adopter client had signed up to foot most of the development cost, the project goals had been established, a target date was set and a contract signed. The project would be delivered for a fixed price. All of this was acceptable to senior management and even seemed reasonable at first. It was understood that the project dates and even the budget might not be “quite right,” but this was a long-term product. A little bit of overrun was to be expected.

As the project director I would be responsible for all technical execution. I would inherit the legacy system’s development team and have the ability to hire a couple of new people if need be. It was an attractive project, but riddled with potential problems. The irony is, I flagged all of these problems before taking the job — and I did it anyway. I was caught up in the persuasive, charismatic message the company President voiced — and two years later I’m reminding myself to keep those cynical biases near at hand.

“Remember that the worst reason to do it is for love.”

It’s important to love your work — in fact, personally I think it’s a requirement. It’s also important that you don’t do it solely for love. I’m a technologist through and through — and that makes my work dangerous. It’s easy to get wrapped up in the moment, to be one of those smart people defending bad ideas. What I need to be is a smart person defending a smart idea — an idea with all the right elements to evolve into a brilliant product, support a viable company, cross to the early majority market and achieve success.

Be objective in your analysis. Long ago someone gave me this advice: “Never invest in your own product.” In other words, if you can’t find other people that are willing to invest, you’d better challenge your assumptions. Maybe the idea isn’t well evolved.

“Look for the chasm.”

If you haven’t read Crossing The Chasm by Geoffrey A. Moore, it’s a worthy read, especially in the technology market. The company’s strategy was wrong. One of the most important aspects of product development is considering how the product will make it to market. That means developing a strategy around early adopters as well as the “early majority,” a group that represents the first half of your market research bell curve. The early majority is your cash cow. Make it into the early majority and you’ve got it made. The problem is getting there.

The root of the issue is crossing the perceived “chasm” from the early adopter to the majority. Early adopters are a rare breed of client. Typically they are actively seeking out new technology. They are often willing to take risks the majority avoids and may even fund development of early projects. Unfortunately, there are few early adopters — most companies can only attract a couple, if even that. And to make matters worse, early adopters make costly demands. Because of the concessions the early adopter makes — greater risks, higher costs, early funding to name a few — they demand greater returns. In a nutshell, they demand a custom project that meets their very specific — and yet often hard to define — requirements.

And there is the rub. If you are building a custom project tailored to the picky needs of your first — and perhaps only — customer, how can you evolve it into a product suitable to the majority? Such a product must be suitable to a wide audience “off the shelf,” robust, complete and easy to adopt. Custom solutions rarely meet these criteria.

To overcome the disparity between a hard to finish custom solution and a generic product of wide utility a company must budget time to “cross the chasm.” The transition from the custom, early adopter client to the early majority is often not an easy one. Products must be retooled, marketing messages revamped, new clients must enter into the pipeline (riding, hopefully, on the good recommendations of your first early adopter clientele). This is a critical time and often one that a company fails to plan for. The chasm was largely dismissed on the assumption that existing clients adopt the new product readily yet no transition plan from early adoption to majority adoption existed.

Even if the project goes without a hitch, there is necessarily a transition from the custom project to the generic product. This time must be budgeted, and funding must be allocated. Glossing over such a transition is a huge oversight — and probably the number one red flag for potential failure.

“Requirements are… required.”

Another concern surfaced very early in reviewing the project. The requirements that had been gathered were far from adequate. The entire work of requirements consisted of a tailored and very detailed request for proposals from the early adopter customer and the idea that the legacy software would serve as a blueprint.

These requirements, as an RFP, where actually very good, consisting of hundreds of pages of needs, desires and parameters from the customer. In many regards it was far more complete than most RFP’s — but it had very little to do with requirements per-se. The RFP was riddled with contradictions, incomplete statements and inaccuracies. The technical detail was simply not there but the business treated it like a finished set of requirements.

For example, round-trip integration between a 20-year-old Adabas court information system was summed up in a few sentences amounting to “there will be bidirectional communication with the court information system.” The effort was dismissed as trivial — yet the company ended up investing well over eight monthsof development time on this oversight alone.

“Don’t ignore unrealistic preconceptions.”

During my early discussions regarding this project a certain lack of grounding in the realities of software product development became clear. It’s important that the entire company is backing up a new project. That means aligning resources and setting goals in such a way that growth into a viable second-stage project is possible.

An early conversation I was a part of should have received more attention from me. “Once we finish the first release, we’ll be able to reduce staffing. Future versions of the product will require little or no additional development,” posited the company President. This attitude surfaced repeatedly, lending pressure to “finish” quality assurance efforts so that we would stop spending money on testing. My initial reaction was simply to dismiss these ideas, thinking that as feature requests, client demands and the realities of business growth became clear expectations would be corrected.

Unfortunately, pressures from the business alone are not enough to change deep-seeded misconceptions. This was a battle I ended up fighting repeatedly. Ultimately, the idea that the development effort should beshrinking rather than growing to accommodate a larger market contributed to the “chasm effect.”

“Avoid compromising on methodology.”

“We already have a contract, we know what we want to do, and really it’s OK if you go over budget. Let’s just get to work.” Sounds great doesn’t but? But it never really works that way. The realities of a business mean that your board of directors is watching the bottom line — unless you happen to work for Xerox Parc, stick to your methodology. Plan your project scope, development an lifecycle, and treat your business as “the customer.” Follow through on every aspect of iteration planning and delivery.

In retrospect I can say that a casual business attitude (such as evidenced by the statement above) is probably the most dangerous situation to get into. Customers will hold your feet to the fire. Investors want to see progress. Paying clients will demand quality and new features. But a seemingly casual business owner isn’t going to stay casual for long. Eventually the project schedule starts to matter. Follow your methodology, emphasize communication and frequent releases to keep the business in the loop, and don’t believe for an instant that it’s OK to take a shortcut. Inevitably, those shortcuts come back to bite you, quite often in the form of misunderstandings around schedules, features or capabilities.

“There is no substitute for a clear contract.”

Don’t buckle under pressure to get things rolling. I’d say at least half, if not more, of my projects have started with pressure to begin work with no contract in place. Clearly, starting work without a contract is in the client’s interest, or at least it seems to be. But what happens when the team is several months down the road and issues start to arise around responsibilities, client involvement, payment schedules and procedures to resolve these matters?

In the worst case you can end up with a poorly drafted contract that fails to lay out clear guidelines for all parties involvement. In this case, the contract was already in place — and unfortunately, none of these details were well incorporated. This can lead to poor client involvement, a very difficult situation with a demanding, early adopter client. Insist on a clear, well structured contract that makes it clear who is responsible for what activities. Incorporate these procedures into your methodology and risk mitigation strategies.

Technically, the project delivered some fantastic technology, but the cost on the team was high. Long hours and very hard work — and as of yet, no clear pay off as the company still struggles to get over the chasm and find a mainstream market. In the long run, I can’t help but think everyone would have been better served had I stuck to my guns. My instincts were to walk away from the project — and in so doing, provide a clear and concise message that the project could not succeed as it was set up.

Entrepreneurs, particularly those with a strong vested interest and long history with a product, can be terribly persuasive. Years of tuning the message and creating an infectiously exciting atmosphere makes them skilled at converting skeptics. Becoming excited about a product is wonderful, but don’t let the euphoria of the moment overshadow the concrete facts.

Related posts:

1. Common oversights in choosing methodology