In the development of a new startup, a team of project management consultants was organized to develop an RFP to find qualified technical services providers who would be able to build the web site and application at the heart of the new venture.

During the course of the effort, however, something came up which surprised me a bit: a difference among the consulting team about what made good (and even appropriate) requirements documentation and what did not. This surprised me a bit because, after having been doing this for more than a decade and seeing how much the industry and discipline have both matured over time, I did not realize that there were still debates on this matter occurring out in the wild anywhere.

So what are good requirements?
In order to write good requirements, it is important to separate out the “what” question from the “how” question. Confused? Here’s an example:

• Bad requirement: Provide a drop-down list of choices.
• Good requirement: Provide the user the ability to select from pre-determined options.

Why not just go with the first choice? Because telling someone to just use “a drop-down” list is dictating both design and functionality. And if you are providing your functional requirements to a provider – who is presumably an expert – then part of what you are asking for is to create the best, and more technically appropriate solution possible.

Now, we could spend weeks going round and round on the different type of requirements: business requirements, functional requirements, non-functional requirements, user requirements, etc. There are plenty of good analysis breakdowns online for what constitutes which one, who uses which type and why. But the key thing for a good consultant to know is which type of requirements are appropriate for the type of project and the audience — because, I promise you, a non-technical business client isn’t going to know the answer to that themselves. Part of what they are paying you for is expertise on what they need to be providing. In this case, we are dealing with a non-technical client for the purposes of finding them a technical vendor to deliver a solution that will meet the needs of their new business. So, in effect — and my apologies to the purists out there — what we were looking for was a combination of business requirements and functional requirements.

In a world of increasingly vital cross-platform applications (iPhone apps, Blackberry apps, etc.) and new UI-driven technologies (Flex/AIR, Ruby on Rails, etc.) this distinction becomes increasingly vital, because different technologies handle these issues natively in different ways. And while a drop-down menu may just be a drop-down menu, there are other design elements that can inadvertently limit your technology if you aren’t clear on the line between the “what” and the “how.”

Another thing to keep in mind is that — again, in a world of prolific cross-platform application development — wherever possible, you’re going to want to get the most bang for your buck out of requirements documents. This means that, while today you may only be building a website, next month you could need to recycle that requirements documentation out to an iPhone developer to build you an app for that platform.

The design logistics of different platforms are inherently different. Unless you want to have to re-write everything to be platform-specific, cut out the “how” all together and keep the requirements platform agnostic so that you can send them to any vendor for any platform built on any technology.

As a project manager or business analyst the goal is to capture the business’ need in a way that gives a web team the ability to provide the critical functionality with the least amount of unnecessary restriction. The biggest danger in that role is to unintentionally impose potentially costly restrictions without realizing it. By including the “how” instead of just the “what” in your requirements, you are potentially limiting solution options — dictating that X needs to be placed over here, or that the page needs to be subdivided a certain way may not be the best or more logical way for a particular technology to work. As a result, you could be giving your potential solution providers a mixed message. Worse yet, it can be a mixed message that hurts the project.

How We Say What We Say

One of the challenges social media evangelists face is based on the language we use. As with all emerging technologies, the language is new and it’s not compatible with standard, well-worn executive jargon — worse yet, it has the unfortunate tendency to be too “cutsie” to be taken seriously by business leaders.

In order to get past the knee-jerk language reactions, stop using tech-speak and start using business-speak. The business already has a language, so use it. Evangelists can’t expect that the population at large is going to adopt a new language for a technology for which they are not yet onboard. Technologists and evangelists need to remember to speak the language of business.

The value of using the business’ language is clear in everything from initiating change, to clarifying the value of social media, to measuring the impact. In and among all of the ROI debate on social media one key is often over-looked: businesses already measure their efforts. For social media to be understandable to that business, it needs to be measured using metrics those executives already understand, expect and are comfortable with.

The Push-Pull Between Entrepreneurism and Process

As companies grow, entrepreneurism gives way to process until people can sleep walk through their day. Unthinking action is unthinking business. If your business is being run by unthinking people, then your business isn’t innovating.

Innovation is key. Even more importantly, innovation is different. Improving on a competitor’s product is not innovation. To truly innovate you must create something new, you must do it first, and you must own the market space.

Innovation Is Not Just for Products

In order to have innovative products, organization’s can’t fall into the trap of doing things the way they have always done. Instead of highly-connected leaders, most organizations have a collection of independently run fiefdoms. Lawrence calls these “Un-Knights at the Round Table.” In order to have the internal organization necessary to support true innovation, internal silos must be broken down, and all players must re-engage with each other.

One example Lawrence gives of how internal organizational patterns can benefit from social media is in its ability to “shorten the ramp.” Getting new employees up to speed quickly on new roles, projects or teams can be radically improved in organizations that leverage social media. Instead of having to spend six months learning who’s who and where to find what, an organization with an internal social media eco-system (facilitated by robust search capabilities) can provide opportunities to catch up quickly and start contributing to the team’s value much faster than traditional on-boarding processes facilitate.

In Conclusion

Social media has transformative capabilities, but the true transformation is in the people using technology to facilitate change, not in the technology itself. Like so many other lessons learned in social media: no matter how sexy the technology may be, business transformation is driven by people.

And then I got a job — that ultimately turned into a career — at a start-up. Pay dirt!

The transformation that sparked in me is still an endless source of amusement among my friends. It took me a while to realize why, but eventually it was clear: the problem with school is that there was an upper limit on what I was capable of achieving. It was an artificial cap on how well I could be scored. I found that inherently disincentivizing. In business, however, there is no upper limit. You can take something as far or as high as you can push it (given the right environment, of course).

And, even better, in a scrappy, entrepreneurial, risk-taking startup (especially one trying to survive an economic downturn) someone who is hungry, talented, teachable and willing to dive into the deep end of the pool head first has tremendous opportunity for growth. The first three years of my career were the most educational, exciting and energizing time of my life — all of my years of school combined couldn’t compare to those three years. Everything was new, everything was interesting and I never once had the slightest bit of doubt that I could conquer anything that came my way.

Ah, the hubris of youth!

Of course, there were downsides. Like many young people, I didn’t know my limits and was constantly pushing the envelope in ways that I probably shouldn’t have (and in ways that I’ve since learned not to do). Whereas many 26-year-olds may be more inclined to do that with parties, I did it with work. I ended up missing a lot of important events in the lives of friends and family because of that.

I was also still extremely idealistic about a great many things. Instead of The Pragmatic Contextualist, an appropriate blog title would have been something along the lines of The Snarky Idealist or Bring it On and Get Out of the Way! (Which, ironically, is still how some people tend to view me, though I have toned down considerably with age.)

But that idealism was invaluable to me, because it made me fearless: if anything is possible and I’m extremely capable, then what do I have to be afraid of? I don’t tend to be very risk-adverse in general, but I have become more cautious with age (though, not quite enough for either my husband or father’s tastes). Back then, though, it would never occur to me that I wouldn’t figure out a way to succeed at whatever I did — which meant I was a hopeless volunteer junkie.

My biggest rush came from fixing problems, and in a post-bubble burst start-up, there were plenty of things to be fixed. So I had an endless supply of opportunity, and endless confidence in my own success. Happily, I also had bosses who went from having nothing to lose by letting me try, to truly believing in my ability to make a positive difference.

As was inevitable, a few kicks in the teeth later, and I stopped being quite so cocky. The pragmatist in me was ultimately born of those experiences, and the eternal idealist retreated to the back, only to come out for the occasional political event.

One of the biggest, most valuable lessons I learned was how to deal with chaos. More recently in my career, I had a bizarre moment when a senior IT Director — who was easily 25 years older than me — groused that we were working in “the most chaotic environment” he’d ever experienced in his life.

I wanted to laugh and call him a weenie (I restrained myself — though barely). The environment we were working in at the time was easily the least chaotic environment I’d ever experienced, and his inability to roll with the punches made him a particularly weak and frustrating leader in my opinion, because he got frazzled very easily, whined constantly and was tremendously rigid. It never occurred to me until that moment that my ability to handle chaos was all that unique.

Naturally, one of the dangers of getting a bit too used to high volumes of chaos is that you can become a drama junkie. This did happen to me, and it took me a while (and outside circumstances) to curb it. But what I have seen of most drama junkies (and trust me, I wasn’t the only one I knew) is that, the older we get, the less tolerance we have for that same constant fever-pitch of insanity.

This is another reason that I have often recommended aimless twentysomethings seeking career advice to explore startups: because by the time people are settled in their career, married or have kids, startups can be a bit too rough on the lifestyle. So if you’re going to do them, best give them a shot while you’re young, energetic, single and have as few external obligations as possible.

But when I look back on that time now, I am profoundly grateful. I was drinking from a fire hose, and it never occurred to me there was any other way to work. I got to sample a spectrum of potential opportunities and figure out which ones held some appeal, and which ones didn’t. If I had found myself in a more stable, structured environment back then, I can’t imagine where I’d be now, because the lessons I learned there, and the all-you-can-eat-buffet of opportunities that I had available to me at the time are how I found my way into a career.

In the scheme of things, I look back on the most pivotal, impactful decisions of my life and the day I left the famed O’Reilly Publishing — which is where I thought I’d wanted to work for years — and went to MarketLive (at the time it was still called MultimediaLive) was one of them. And since then, I have found myself encouraging twentysomethings who do not know what they want out of a career to look at startups, because as long as they can develop a bit of tolerance for chaos (which I firmly believe everyone should do), they’ll usually find opportunities they never knew existed.

What do you think? Are startups a good or bad place to start out your career?

The fact is, most experienced professionals have lived through enough project pain that they don’t typically need a huge amount of convincing that Waterfall is often inefficient — particularly for longer, larger, more complicated projects. In a fast-moving world, the risk of constantly changing requriements is ubiquitous, and a Waterfall project does very little to insure against that danger while still delivering a valuable product to users.

However, the problem with the “Agile Development” argument is that, in order to work properly, Agile can’t just be for software development. In fact, Agile can’t even just be for your project teams. Your entire business needs to be ready to adopt an Agile methodology.

The trouble is, this conflicts with standard business-model thinking. In his book “Maverick,” Ricardo Semler outlines the critical success criterial for modern business: “To survive in modern times, a company must have an organizational structure that accepts change as its basic premise…” He goes on to discuss the more ‘agile’ approach at his company, Semco, and why: “[W]e take an operation view of six months, because we found that in a conventional one-year plan people will invariably believe that conditions will improve just enough to compensate for the problems they know they’ll have in the first half of the year.”

How many of us have seem Semler’s point in action? In annual budget processes? In project planning? Somehow, some way we convince ourselves that whatever conditions that exist today will be “resolved” and we’ll be able to make up lost ground later. And so our plans are based on figuring that we’ve got a brief rough patch to get past, but once we do that, we’ll have 100% clear sailing. How often does that actually happen?

Of course, just looking out six months isn’t sufficient, either. At Semco, Semler and team have two plans: one with a five-year view to keep an eye on strategic planning, will the six-month view focuses on tactical execution. But isn’t this what we have come to recognize as the definition of “Agile Development”? A long-range goal that we approach in short bursts, one piece at a time.

But if we change “Agile Development” to “Agile Leadership” it not only allows us to approach application development with flexibility and agility, but also the way we look at the bigger picture. Development efforts — whether they are for back office systems, B2C web sites or client engagements — are a means to an end, not an end themselves. We recognize that changes to business conditions are a big part of the reason we get value out of Agile Development, but then we continue to approach management of our actual business as though it were static.

I was recently approached about a “four-year project.” Horrifyingly (yet predictably) enough, this was a Waterfall technical project (for a government agency). In technology terms four years is an eternity. The idea that any team (or group of teams) would be spending four years and tens of millions of dollars on developing and implementing a technical solution for anything is insane, because no matter how good your requirements are this year, by the time the project is complete (assuming it is actually complete in four years) the entire world will have changed. Four years is an ice age when it comes to technology, and it’s at least a lifetime when it comes to business.

So what would need to change if we applied “Agile” methodology to an entire business, intead of just the development teams? Consider this:

• Evaluate the business from end-to-end and examine how much is truly “operational” and how much is “project-based.” Your operating models, staffing, budgetary and expectations are all different for the different sides of the organization. And, in many cases, most people should have a mix of both to keep business moving while also getting new work done and keeping employee engagement as high as possible. But we need to truly stop and look at this, because without first understanding how much time people have to dedicate to project work, we never build realistic project schedules. How many project plans assume each team member spends 8 hours per day on the project? Does that ever really happen?

• All projects would be time-boxed to ensure that, even at their longest, nothing dragged on for more than six months. This could be done by breaking large-scale projects into multiple smaller projects all organized as a program, or by breaking a single long project down into phases. But no matter what, no one phase should ever last too long. And at the end of every phase, a re-evaluation is done before proceeding to the next. How often have we worked on a project only to realize half way through that the work was really no longer necessary? Aside from being an irresponsible financial sink hole, this is also extremely bad for team morale.

• Consciously examine the value of ‘domain expertise’ versus ‘fresh blood.’ As a career project professional, I can tell you that most leadership underestimates the value of giving a project team a new project — even if it’s the second or third phase of someone else’s project. The assumption that it is better to keep the “experts” in place rather than to get fresh blood looking at a problem is often assumed instead of explored. And while there can be some value, is the value found simply because the original team didn’t do a good job of documenting their work? Or is it just a simpler resource model. In my decade of project management experience, I’ve seen keeping the same team on a project for a long time do more harm than good. And I’ve seen very little formal evaluation done to ensure the decision was actually being made instead of merely assumed.

• Strategic initiatives like new product development make an agile approach particularly valuable. Market conditions change rapidly and outside factors can move a low-priority, nice-to-have product from the bottom of the list to the top of the list over-night. If you’re planning too far out in too much detail and with too much rigidity, then you are not leaving your team the ability to react quickly enough to stay ahead of the curve. In fact, even worse, if your planning goes out too far, you end up inadvertently discouraging your people from staying abreast of the latest trends and changes, because they get into a ‘heads-down’ mentality, focusing on the long list of things they know are going to be occupying their time for the next year plus. This is one of the ways that companies lose their edge entirely.

Budgetting may be the biggest one of all, because we have been conditioned by most modern business practices to think in terms of quarters and years. Quarter-by-quarter planning is often too frequent to be efficient, but year-by-year is often too far out to be realistic. And, worse yet, it’s not far enough out to be strategic. It’s a combination of timelines that often work at cross purposes: we scramble like crazy for end-of-quarter numbers, and then we speculate wildly when building out year-long budgets. And in the end, neither is usually very valuable to getting things done.

How many organizations with large expenditures on gasoline and/or natural gas of some kind had to stop what they were doing in the middle of 2008 and completely level-set their budget for the year, because the unprecidented cost of oil had made all of the year’s original numbers (no matter how conservatively planned) entirely meaningless? Trucking companies, airlines, agribusiness, shipping companies, etc. All of them, because at the end of 2007 when planning the 2008 budget, you would have been hard-pressed to find anyone who would have predicted that gasoline would top out near $150/barrel. (Hell, most people thought they were being generous if they budgeted for $100/barrel.)

I have seen two common outcomes to this process: either everyone spends weeks creating their budget for the next year based on wild speculation and generally accepted (often inacurate) assumptions, and then they are held to it kicking and screaming, missing one opportunity for market adaptation after another; or the organization stamps the budget as “FILED,” puts it in a drawer and never looks at it again, rendering the entire exercise valueless.

And while the 2008 oil roller coaster is an extreme example, this type of thing happens on smaller scales all the time. And so we plan optimistically and then make exceptions for all the things our plan didn’t account for. Josh Ross has an interview (ironically, shot the day after the mother of all recent unplanned disasters: the collapse of Lehman Brothers) called We Design For Possibility and Retrofit for Risk. And although he is specifically talking about Web 2.0 and information security, in reality that title applies to business in general.

We plan aggressively, assuming all will go acording to plan, and then we try to put out fires that errupt en route to our goals. Instead of sprinting in shorter bursts that allow less time for disaster to erupt, we take a marathon mentality that gives the world around us time to throw obstacles in our path over and over again.

Like so many other normal, mundane facts of our daily lives, the way we approach business is still largely rooted in Industrial Age thinking — it’s a model for which the Waterfall method makes sense. The time and cost to build something new is so high that you better make damn sure you know what you’re doing before you start. But as we transition from, as Chris Anderson puts it, the ‘economy of atoms to the economy of bytes‘ we trade in more and more investment cost for higher and higher opportunity cost. If we don’t start pushing ourselves to thinking, planning and acting like products of an Information Age, we will continue to pay the price for a lack of innovation and agility. And the more time goes by, the more of our competitors will make the change around us, the more we have to lose by burying our heads in the rubble of the Industrial Age.

That is, until we started talking in more detail. It suddenly occurred to me that, much like Krishna De‘s article yesterday about using blogs to attract customers, there needs to be more thought put into using blogs to service the customers you already have. “Engaging customers” is a wonderful buzz phrase, but there is real work behind those two little words. If you are not prepared for it, you could be in for a rude awakening.

As a compliment to Krishna’s questions, I would like to add the following three questions to the discussion: Who? What? …and How?

Who is going to be responsible for writing the content for the blog?

Is it the Marketing team? Or is it a cross-section of capable writers from other parts of the organization? Are the people doing the writing intimately familiar with your product line enough to speak to it in detail? Do they know the types of issues and challenges your customers face every day? And are they equipped or empowered to respond to those issues, if posted to the blog?

If we use a B2B or SaaS-type software company as our model, then I would recommend that writers from different parts of the organization are tapped to produce content that has a cross-section of relevancy:

• The Sales team can write great success stories of growth increases and wonderful ROIs.

• The Product Team can discuss little-used or new features; they can get feedback from customers on the newest releases and collect ideas to help prioritize future ones.
• The Design Team can offer tutorials to customers on good design practices, and usability considerations to keep in mind.
• The Implementation Team can provide suggestions and recommendations for the types of things that make a new implementation run smoothly.
• The Customer Service Team can help educate on the maintenance and upgrade process, on-going customizations capabilities and new feature training and applicability.
• The IT Operations Team can provide practical tips for good data security and can use the blog to speak to customers about routine maintenance windows or incident reports.
• The Quality Assurance Team can create a coaching series designed to help customers understand what the testing process looks like when they implement a customized project.
• The Marketing Team can provide tips designed to help your customer-base launch an effective marketing campaign – with either their customers or their employees.

The options are really endless, and this is precisely the type of information that often helps customers understand (and be more patient with) the process a company goes through to provide their services.

The last thing you want is for your Marketing Team to be trying to engage with your customers as though they are experts in all of these areas. Marketing people are experts in Marketing. Limiting your blog’s authorship to the Marketing Team only makes sense if what you are trying to engage your customers about is their marketing campaign.

A great example of a company blog that represents a broad spectrum of an organization’s disciplines is Convio‘s. Their blog, The Connection Cafe, is team blog – but not the Marketing Team. Their team is made up from people all across the organization, who work with clients in every different capacity throughout the client implementation life cycle. If you look at the Authors page, you’ll see the array of groups represented – starting with the CEO.

Not only does this provide article content that meets the needs and interests of clients at all different maturity levels and in all different stages of implementation, but it also keeps the blog from being monotonous to read and onerous to write. The Marketing Team owns the process, the writing standards, and the responsibility for ensuring that the content lives up to their guidelines, but they do not do all the writing.

What are you hoping to provide to your customers by engaging with them in the blogsphere?

This is a dangerous one, because all too often the answer to this question reveals that a company is less interested in having a “dialogue with” their customers than a “monologue at” their customers. And if that’s what you want, then skip the blog.

What is your organization’s relationship with your customers? Are they generally happy, or are they generally hostile? Do they feel like your organization is responsive to their needs? Or do they feel like once you’ve cashed their check, you’ve stopped caring about them?

Whatever the general consensus is among your clients, be prepared for the fact that if you get them to engage with you on the blog, that sentiment will be made very clear at every turn. And if you are not prepared for how to respond to it, then stop, count to ten, and figure out how you would before you move ahead.

There is very little that helps turn around troubled client relationships better than directness, honesty, and transparency. The only thing that works better is results. So if the team that is doing the blogging is completely disconnected from the teams who can solve the customers problems, then beware of setting everyone up for disappointment – and setting your customers up for a revolt.

It is not realistic to ask your customers to be involved in a dialogue if, as an organization, you are not committed and prepared to try to resolve (at least some of) their issues. But if the customer blog is completely removed from the operational planning of the organization, then you’re simply giving your customers a megaphone so they can scream into a well. And that’s just going to upset them more.

Do you know what type of functionality you really need in a blog yet?

It could be all of my years in small businesses and startups, but this one never ceases to amaze me: instead of starting small, with a local installation of WordPress, a company decides to spend a fortune on something written in a proprietary language – and this is all before they have any idea if their customers even have any interest in engaging with them via a blog.

Stop. Put the checkbook down. Back away.

I don’t care whether you call it a “beta” release or a proof of concept, but in these tight economic times, if there is one piece of advice I have for any Enterprise 2.0 evangelists out there, it is this: Don’t shoot yourself in the foot by asking for the moon unless you’re sure you really need it.

Times are tight. Budgets are being slashed. And ‘frivolities’ are frowned upon. While I would never classify a customer blog as a ‘frivolity,’ it is not uncommon that it is a hard sell to an executive with budgetary authority. Make your limited funds count.

Time and time again, we see that the organizations with the greatest success in Web 2.0 are the ones who are willing to experiment. But the only way to afford to experiment is to keep the proof of concepts affordable. The first time you ask for $80k for something that quickly turns into shelfware will be the last time you are given a check for $80k.

Start small and build. It is much easier to make the case for resources – financial, technical and human – once your leadership team has tangible proof that your customers are finding value in your corporate blogging efforts than it is when it is all just a theoretical experiment.

But $80k is an employee’s salary for a year, so don’t be reckless about spending it. The last thing you can afford to do is to spend money foolishly only to have your efforts wither on the vine. If that happens, you can be sure the next time you need funds for another social media effort, you’re going to have a much harder fight on your hands.

One of the beauties in Web 2.0 is that affordable solutions can be found everywhere. And no, they may not have all the bells and whistles you are looking for, but an organization that is dipping its collective toes in the water needs to start somewhere. You have to walk before you can run. Once you’re up to speed, then that fancy platform might make sense, but until you know for sure, don’t burn bridges by unnecessarily burning through money.

I’m a big fan of the value of blogs as a customer service tool. But remember, your marketing people are not your customer service people. What people look for in social media is authenticity – they know it when they see it and they know when someone is faking it. So don’t try to have a marketing team pretend to speak for all of the other departments in an organization. Get the other teams involved, and let Marketing direct the efforts (or be the “project manager,” as it were). Not only will you get better results, but you’ll also be far less likely to burn out your writers and bore your readers.

Cross-posted at Social Computing Magazine.

Those of us in the Web 2.0 space who come from a technology background are often a little stunned when we discover that it is frequently our IT cohorts who pose some of the biggest obstacles to prospective enterprise implementations.

After all, wouldn’t it be better to use (for example) a SaaS or cloud computing solution for something, rather than bring yet one more department-specific application inside the firewall, for an already over-stretched staff to have to support?

Of course, in a totally rational universe, this wouldn’t be in question, but when it comes to change, ration is frequently shouted down by emotion. So in that spirit, I present five recommendations to employ when attempting to introduce the advantages of Web 2.0 to your reluctant enterprise, including (potentially) your IT Department.

1. Start with the lowest of the low-hanging fruit

   This is, without a doubt, the most important thing to remember when trying to get your organization on-board with the value of Web 2.0 capabilities. Every single organization has something, somewhere that can be made much easier – you just need to look for it.

   I was working in the IT Department of an industry-leading organization which had virtually no standardized project management tool set or methodology. And yet, being a project-centric organization required that each Friday everyone provide status reports. For years, each person put the information in their own format – a bullet list in Outlook, a template in Word, an Excel spreadsheet, a PowerPoint presentation, whatever worked best for them. Team members would provide status updates to project and functional managers, who would roll up their view to their director. And then the Directors of each group would consolidate everything, and hand it off to the department admin, who would spent a whole (long and tedious) day manually pulling everything together into a single, semi-cohesive document for the CIO and the rest of the executives. Not only was it a nightmare for all involved, but it was bad enough to make people actually dread Fridays.

   While I would love to balk about how rare that type of thing is, I would be lying if I said that. Endless time wasters like this are commonplace, and any objective observer would be quick to point out that they are an insane and expensive waste of time. So, our goal was to find a way to make this onerous, tedious and thoroughly unpleasant task easier for everyone. The “selling point” was not about how much greater information it would provide; it was not about how we would be able to track trends week-over-week; it wasn’t about gains in leadership oversight. There was nothing altruistic or theoretical about the goal. It was 100% tactical and immediate: “Look at how much easier we can make your life!”

   After some very quick-and-dirty SaaS tool comparison, we selected the extremely flexible and ridiculously affordable Intuit product, QuickBase. Literally, in less than 30 minutes, we had created an app, defined the fields we wanted people to fill in, and started adding users to invite in and use the system.

2. Start small

   Sure, there are tons of things that might fall in the “low hanging fruit” category, but find a small one – like status reports, time cards, or a team calendar – something that can be localized and does not require cross-departmental coordination. Limit the scope of what you are trying to do with the first iteration.

   What proved so profoundly valuable for our QuickBase implementation was that, once people realized how much simpler it was to fill out three fields of information instead of sitting in front of their computer for an entire morning worrying about formatting and what details matter and what details can be omitted, it streamlined the whole process. Additionally, once it became clear that the reports the system could generate were just as valuable and ready-to-go out to the stakeholders in other departments as they were for IT Leadership, then it offered each person the chance to even further cut back on the amount of time they spent writing status reports each week.

   Because we started small, and with something that had previously been such an on-going source of pain and frustration, our user base became the biggest advocates for the tool, pushing to use it more and more. And because of the degree to which it also offloaded work from the management team – and provided the much needed visibility for business units and executives – the internal department leadership became our core champions.

3. Pick the most non-threatening tool you can find

   There are two sides to this point.

   First, when you select a tool to implement, go with something that is not intimidating. Obviously different groups are used to different levels of UI sophistication, so you might have more leeway with a group of developers or engineers (as an example) than you would with call center agents, but whatever it is, it needs to be very accessible. Again, an SaaS solution lends itself to this very, very nicely because it’s browser-based, which is essentially native to your users. A product with a strong brand behind it can also help as well. While that might seem a bit dumb to someone looking purely at functionality, don’t underestimate the ability of a reputable brand name to put people at ease when you are taking them out of their comfort zone.

   Second, part of what it takes for a tool to be ‘non-threatening’ is that it can’t be usurping the tool (a.k.a. “territory”) of someone else. The fastest way to bring organizational change to a halt is to bring an outside solution in, when someone else owns the current solution. If you can get them onboard as an evangelist, that’s great. But, if possible, start with a problem that does not currently have an established tool set designed to fix it, and you will encounter far less resistance from people who feel possessive and threatened by a new solution.

4. Use a beta group

   This is another one that seems obvious, but I am constantly surprised to hear about attempted roll-outs that were enterprise-wide right out of the gate — and then I’m even more surprised to hear that people are shocked when it encounters obstacles and resistance. There is great value to having a subset of your user base dry-run the system. For starters, getting their feedback gives you the chance to iron out any kinks and avoid the nay-sayers knee-jerk negativity the first time they see something they think is “wrong.”

   But secondly, if the beta group is experiencing success with the tool, word will spread. Fast. And it won’t be long before you are having to fight off other volunteers to get in and be allowed to use the system. This is not fakeable, though, and a lukewarm beta group doesn’t build anticipation among the general population. Your beta users have to have genuine excitement at how much of an improvement your tool provides in order to help fuel the fires of those waiting in the wings.

5. Leverage momentum to iterate

   Build on success. Once you’ve got your users appreciating how much help your tool has provided, and once your leaders are on-board with how much better visibility/metrics they have, it’s easy to start branching out. If you started with status reports, then roll in project charters or time sheets. Pick whatever the next ‘lowest hanging fruit’ is and see how you can dovetail it together. Once your users are in the habit of going to a single tool for one thing, it is increasingly easy to add more capabilities in over time, because they get increasingly used to and fluent in the system. Whereas if you try to do it all at once, a perfectly good solution can be wasted on resistance and culture shock.

   This is where our use of a straight forward, flexible and highly customizable tool like QuickBase came in handy in my change-resistant organization, because it was easy to evolve it to include more and more capability with just an hour or two of administration. What started off as simple status reporting for projects within the IT Department turned into an enterprise-wide array of department-specific and inter-departmental communications and coordination applications revolving around projects, marketing campaigns, design collateral, calendars, strategic communications programs, training schedules, and call center support functions in less than a year – because the first time someone saw a report out of the system, they immediately wanted to know what it was and how they could leverage it, too.

Sure, there are things you need to do – making sure you are clear on the security standards and how you go about ensuring that no one is putting data in there that isn’t appropriate for the system. But the reality is, that is a risk with employee laptops as well. If you start with small, non-sensitive data and a straight-forward, unobtrusive tool, it is much easier to engage your leadership teams to help evolve your internal processes over time, as the capabilities of your tool set – and the organizational behaviors that go with it – also evolve.

A common danger in all change management is trying to push too hard, too fast and not stopping to recognize that the people need to be the focus, not the tool. Starting with something small and innocuous is the easiest way to start getting everyone used to the idea of leveraging new solutions that they may not have previously been willing to consider. Remember that your goal is to change attitudes first, so that future solutions will even be seriously considered.

Small changes may not be sexy or exciting, but they are the most reliable path to success, so don’t dismiss them simply because you think they are indicative of ‘thinking too small.’ When it comes to driving change, the turtle is always a safer bet than the hare.

(Note: Contrary to how it may sound, I have no actual formal affiliation with Intuit/QuickBase.)

And particularly at a time when so many people are suddenly finding themselves facing (potential) layoffs, it is often the opportunity to explore making a change. So for people thinking about making this change, I have a few stock recommendations to make:

1. Join The Project Management Institute
Not only join it, but list it on your resume as a Professional Affiliation. Joining PMI provides value in several areas: it bolsters your credibility to be a member of the organization that is regarded as the standard-bearer for the industry; membership automatically subscribes you to PMI’s regular publications, which are great learning tools for practitioners; it provides networking opportunities via local chapters in your area or field-specific Special Interest Groups (SIGs); and it provides discounts on training materials, events and certification tests. All in all, someone who is trying to break into project management cannot afford not to join PMI. Of course, as with anything else, it is not just enough to join PMI, but to actually take advantages of the resources they have to offer.

And an added bonus, if you are a student at all, you are eligible for the student discount on membership, which brings the cost down to a very affordable $30 per year.

2. Start Studying
Increasingly, local community colleges are offering courses in project management as part of their business programs. If that’s not an option for you, then look online for programs that cover project management basics to get you started. Beyond that, be sure you are reading the publications PMI sends you, and find online blogs and publications specific to project management that you can make a habit of reading. (See the Project Management section of my links page for specific examples.) Like all disciplines there is a special “language” project managers use. In order to convince someone that you can walk the walk, you must first show them that you know enough to talk the talk. So find a mentor you can learn from, attend networking events (which you should always be doing, anyway) so that you can hear about other people’s experiences, and give yourself the chance to start working on your elevator pitch. It’ll take time and tweaking to get it right, so better to practice over cocktails than to wait until you’re in a job interview.

3. Get Certified
Almost anyone breaking into project management is immediately faced with the daunting discovery that getting a PMP requires years of work experience in the field before you are eligible to take the test. Yet a surprising number of people do not realize that the CAPM, the Certified Associate Project Manager, test does not require anywhere near the same experience (not to mention that it’s an easier and shorter test) – in fact, your experience can be as a member of a project team instead of the leader. And don’t worry about finding CAPM-specific study and training resources. Use those designed for the PMP. The test is made up from the same database of questions used to construct the PMP, there are just fewer of them, and they are basically limited to the text of the PMBOK, instead of relying on as many scenario-based questions.

(Quick note here: the current PMBOK standard is version 3.0. The newest version just came out at the first of the year, and is version 4.0. If you expect to take your test prior to this summer, you will want to target 3.0 before it is phased out. But if you do not expect to get to the test before the second half of the year, then get the materials to prep for the 4.0 test. There are enough changes in terminology that you’ll be better off if you are sure to prep for the version of the test you will be taking.)

And while the CAPM is definitely the “junior” certification, it demonstrates both your commitment to your transition as well as a basic grasp of project management fundamentals. Even better, the nation-wide salary average between CAPMs and PMPs is actually very small.

4. Re-write Your Resume
As I’ve said before, throughout my career I have been a project manager, even though there were many times that was not actually my title. So part of what my resume has to reflect is that I have gained project experience in each role that I have held. It is entirely reasonable to assume, that if you have spent a decade in most any professional field, you have probably developed more project management experience than you may realize. What’s even more important to understand is that, as soon as you start studying and learning about the formal steps involved in project management, that you’ll begin to recognize patterns in your previous projects that help you understand why some failed and others succeeded.

So start a list: list each position you’ve held, and then under that, list each specific project that you actually managed or participated in. Remember: a project is a temporary endeavor undertaken to create a unique product or service. So an IT Manager who built out a NOC in a data center, or a teacher who developed and rolled out a new curriculum across a school district, or an office manager to developed and deployed a new hire on-boarding process, or an HR specialist who crafted and launched a new benefits program are all examples of project leaders, and in almost no case would that person have previously held a job with “project manager” in the title.

Once you have this list, use it to start building a functional resume. Even if you don’t end up using this in a job hunt, it will be a worthwhile exercise for you to understand just how much project management experience you really do have. (Though, in reality, it is not at all uncommon for project managers to use functional resumes, specifically because it is a great way to focus our readers to the experience we most want them to see.)

A cautionary note: project management is most often associated with two very specialized fields: information technology and construction. And while these two fields are highly specialized, they are most definitely not the only ones that use project management and hire project managers (or hire managers with project management expertise). Business Process Improvement projects are one of the most common types of non-IT/construction projects that managers execute, so don’t make the mistake of thinking that if you’ve never lead a team through testing use cases for deploying a CRM that you do not have any project management experience. It comes in all forms, and — along with managing people and daily operations — is usually one of the fundamental requirements of any manager, in any position.

One last word of advice: as the economy terrifies (or forces) companies into laying off their staff, the market is awash with highly experienced project managers, including the always-bright-and-shiny PMPs. If what you really want is to get into the field, then don’t get discouraged. Your expertise in another field is something you want to use to your advantage, not hide from. Businesses seek out employees that can provide value, and while there is great value in effective project management, the trick is to show how several years in a specific field or industry can help make you a better project manager. Maybe it means finding the ideal niche market, e.g. a teacher leaving a school district to work as a project manager for an educational software firm or textbook publishing house; or a career HR Benefits professional leaving in-house back office functions to work at as a project manager for Charles Scwabb; etc.

There are lots of options, but as you work on re-branding yourself, don’t put so much effort into demonstrating project management experience that you short-change the rest of your experience.

There is a built-in occupational hazard in this, of course, and that is that most things can be framed as projects. I was once having a conversation with some project managing friends, and one was talking about how she planned and executed her move from one state to another as a project and tracked progress in Microsoft Project; and another friend scoffed at me when I implied that I did not approach hosting a dinner party as a project… until she stared me down and got me to admit that I really did. She knew that, of course, because she does the same thing. My husband teases me because I put grocery lists in Excel and our personal goals in MS Project with milestones and action items tracking our progress.

I’ve managed departments and people, and yet doing either of those things well invariably also understanding how to manage projects. Helping staff accomplish personal and professional development goals is often best done as a project: identify the goals, determine a reasonable timeline, outline milestones, establish check points, and procure the necessary resources to make it happen. Managing a department is a combination of managing operations as well as a series of projects designed to execute change that is necessary as an organization grows and evolves.

There is a classic management expression that says: “If you can’t measure it, you can’t manage it.” Project management is about a providing a framework so that whatever your “it” is, you can not only measure it, but you can actually manage it to successful completion.

Aside from the amusing little occupational hazards of being a career PM, I have also found a great deal of personal development value in what I have learned in my professional life:

Be pragmatic – A project manager’s job is to make things happen, to do it efficiently, and to be realistic. Idealism can be a wonderful, inspirational quality, but pragmatism is necessary to get things done.

Pick your battles – This is an aspect of pragmatism to be sure, but it is even more than that. It is knowing how to read a situation to understand which battles are going to cost you, how much and whether or not your personal/political capital is best reserved for another time and place. This is about reading and responding appropriately to the context in which you are working.

Success requires communication – Being a project manager requires that you recognize that everyone involved has a vested interest and their own point of view, and that effectively communicating with them about the project requires recognizing, respecting and understanding their position.

Break it down – Life’s biggest challenges are always most intimidating when they seem too big to manage. Since project management is about identifying how to break down solutions into actionable, measurable pieces, this skill is always applicable no matter what you do. Breaking a problem and/or solution down to it’s basic building blocks and then working out a plan that meets the requirements of both the individual piece as well as a plan to integrate everything back together into a cohesive solution is critical and applicable to all aspects of life — whether it’s planning a wedding, moving from New York to Texas or finding a new job.

What I love about project management is that it has given me a way to view the world, to keep it from being overwhelming (at least all the time), and shown me how to define and measure my own opportunities for success. Even more than that, it’s provided me with microcosms in which I have had the opportunity to discover new business models and new organizational styles to see what lessons I can learn and then how to re-apply the most applicable ones someplace else.

As I’ve been looking for a new role as part of the move to Austin, I have been struggling with whether or not it does me more harm than good to brand myself as a “project manager.” But the fact is, even when I am careful to call myself something else, when I look around me — at my life, my business dealings, my goals — I see a series of projects. So what has become painfully clear is that, no matter what title anyone applies, project management is now just a part of my intellectual DNA and it’s probably not particularly helpful to try to define myself (either personally or professionally) without recognizing that a huge part of how I look at the world is a by-product of being a project manager by trade.

Fortunately that’s not a terrible price to pay, since I do really love what it has taught me and the opportunities it has brought me.