Our blog is just another place where we can connect with you. Join the discussion, so we can learn, share, and grow together. Because knowledge is power!


The DelCor Connection

4 ways to de-stress at work

(Everything Else) Permanent link

on meditation: don't just do something, sit there!

As I journeyed home to DC during rush hour, my car came to a standstill before the turn onto Rock Creek Parkway. Waze reported, “There’s been an accident,” in its cybernated voice before rerouting me through the city. Zipping my way down 24th Street, my car screeched to another standstill as an ambulance attempted to zig zag through lines of heavy traffic before eventually stopping on the corner of my exit, next to a stunned cyclist who had been grazed by a car.  I passed a total of 3 accidents in my attempt to make it home. No doubt, this is a normal commute for many professionals in the DC area and a daily exercise in patience, fear, and forgiveness. “Just breathe,” I thought to myself as I dialed my husband to tell him I’d be late getting home.

Professionals have been looking for ways to de-stress, center themselves, and breathe long before the office zen gardens and 1960s Mad Men daylong happy hours gained popularity. So how exactly are professionals squeezing in opportunities to de-stress and unwind these days when mobile technologies allow us to be connected at all times? How the heck do we disconnect?

As a self-help junkie and previous meditator (okay, I did it for a month once, and it worked, but then I had a kid…), here are 4 methods I’ve collected from friends, books, colleagues, and other working professionals that are time-tested and work no matter how busy your lifestyle:

Pink Noise – I’ve had several conversations recently where the power of pink noise has been discussed. Most of us are well aware of the use of white noise, but apparently there are many different “colors” of noise that carry different properties that allow an individual to feel focused, sleepy, relaxed, energized, or calm. Pink noise is used to help with productivity and concentration, so give it a whirl if your Spotify playlists are too distracting. There are a number of pink noise apps you can download, or listen to this recording of pink noise on YouTube.

The 5 Minute Dance Break – I first heard about the 5 Minute Dance Break from a friend who was attending Mama Gena’s School of the Womanly Arts workshop. The 5-minute dance break is an opportunity to get up from your desk at one time every day and dance uncontrollably to the energetic song of your choosing.  The goal is to let go of all your inhibitions and move. Even if you’re in a cubicle, maybe your daily dance break will inspire your neighbors!

The Noon Mantra – Do you have a powerful mantra that you’ve created? If so, memorize it and set a daily calendar appointment to sit and reflect on that mantra, concentrating on your breath. You can also write several mantras you wish to remind yourself of and write them on index cards. Leave them in areas that you frequently visit – your desk, a drawer, your car’s dashboard. If you don’t have time to create your own, you can download the Spirit Junkie mobile app and receive a new daily mantra sent to your cellphone. 

Gratitude Journal – Keeping a gratitude journal is a powerful way to reinforce a positive mindset – and it doesn’t have to take a lot of time. Maybe you’ve heard about gratitude journals from Oprah or spiritual leaders. Your journal can be something as simple as writing down 3 to 5 things you are grateful for at the end of the day (or throughout the day) to remind yourself of what has been given to you. There’s an app to keep this Gratitude Journal too, of course. 

Next time you’re feeling panicked or stuck in traffic, try one of these techniques to unwind or refocus.

What are your techniques for de-stressing?   

Flickr photo by Catherine Nomura

Dear Del: Is it time for an upgrade?

(Project Management, Tech Tips, Innovative Ideas, Dear Del) Permanent link

Dear Del, 

My software vendors said it's time for an upgrade. What should I do to prepare?

_Dear Del_ college school girl daydreaming while writingUpgrades are a great opportunity to review your software, customizations, and business processes, as well as to plan for any adjustments. If you're going to make changes to the software, make sure the upgrade supports (or improves) existing processes. Coordinate changes with your vendor.

You may find that it's easier to make changes as part of an upgrade. You might choose to upgrade then fine tune the application.

Here's a short checklist that may help as you embark on the upgrade adventure!


  • Create an upgrade plan (this is a project!)
  • Identify staff members who will be part of the upgrade team
  • Draft an upgrade schedule
  • Reserve a conference room or space where staff can test the upgrade
  • Develop a process to share questions or failures
  • Discuss the upgrade process with your vendor
    • Do any of the features impact high-volume or high-risk processes at your association?
    • Has any custom functionality been replaced by baseline features?
  • Review new features and changes to the product
  • Review test plans from past upgrades or the implementation
  • Don't have a test plan? Make one
  • Review your organizational and departmental goals
    • What goals are supported by this product?
    • Are any changes needed?


– Gretchen Steenstra, PMP, senior consultant, technology management


How to judge responses to a request for proposals (RFP)

(Project Management) Permanent link

weight station scale open

What do you do when all the responses to your RFP look good, or it seems like you’re comparing apples and oranges? How do you decide which one to choose? How do the judges on Chopped do it? We don’t have the inside scoop on cooking competition shows, but we’ve helped hundreds of clients select the best solution and vendor for them.

Develop selection criteria and weighting.

Let’s back up a bit. Before sending out an RFP, develop the criteria you will use to make a selection. You can certainly adjust this if you discover new criteria while reviewing responses, but the more you can eliminate bias from your decision and agree upon what’s most important, the more likely you’ll choose a solution that truly meets your needs. This also comes in handy when leadership later asks on what basis your choice was made.

Examples of selection criteria could include:

  • System objectives/desired functionality
  • Experience (especially with similar associations)
  • Financial viability
  • Staffing, including the breakdown of staff (e.g., developers, PMs, etc.)
  • Understanding of the project
  • Integration experience/capabilities
  • Corporate philosophy and methodology
  • Support after launch
  • Training
  • References
  • Vendor reputation
  • Price

Establish a weight for each criterion; for example, price might have a 10% or a 50% weighting. Think about how you’ll evaluate subjective criteria such as responsiveness, likability, and personal interaction. How much weight do they get compared to other criteria? The total of all criteria should equal 100 (no matter what your high school coach said, you cannot give 110 percent!) and should provide a useful basis for group discussion regarding vendor selection.

Review and score the proposals.

As proposals come in, let each vendor know that you received theirs. This is a good time to remind them of the next steps you will take. 

Before scoring, review the proposals to see if any have incomplete or ambiguous information. Follow up with vendors on missing information and any points needing clarification. Ask additional questions if it will help. 

Take note of the vendors who didn’t completely provide the requested information. Their error may be an unfortunate once-in-a-blue-moon oversight or it may be a sign of things to come. Don’t judge yet, but keep this in mind as you move forward. 

You’ll find that a solid proposal is actually a good learning opportunity and will help you better evaluate other proposals. Ask vendors to address any inconsistencies within their submitted proposals.

Determine the breadth of your review process. Typically each member of the core project team evaluates and scores the proposals on their own. Then the team meets to discuss, compare, and agree on a consensus score. If your organization requires a broader exposure to proposals, the review team may expand (which could further complicate matters); that said, a well-balanced core project team has representation from all key areas of the association.

While scoring proposals, keep these questions in mind:

  • How well does the proposal speak to your needs, challenges, and goals?
  • How much attention did the vendor give the proposal? Is it boilerplate or sloppy? For example, is another association’s name on it? Seriously, it happens.
  • Do they “get” associations? Do they have experience working with associations like yours? Will they understand the culture and politics involved?
  • Do they talk about how their strengths will help them address your needs or do they mention competitors’ weaknesses (“talking smack”)?

Price is important; but your system, technical, and support objectives are most important. If there’s a large range in price, talk to the low and high bids to find out why they came in at that number. Remember to treat each proposal with confidentiality and respect.

If the timeline presented is very different from yours, find out why. Maybe yours isn’t realistic. Speaking of timelines, let the vendors know if you’re running behind schedule; this is just another example of the importance of properly setting and managing expectations through good communication, which is essential to any technology project.

Spend time with the finalists.

At this point, you should only be considering proposals from 3-5 vendors because you narrowed down the field of prospects before sending out your RFP. Take time to speak to each of the finalists still in the running. Yes, it’s time consuming, but it’s a critical step. No matter how complete the proposal, it can’t tell the whole story. There are limitations to the written word. Your team and your prospective vendor partner need the opportunity to evaluate the critical components of a relationship – personal interaction, chemistry, and communication – before any decision is made.

Ask each vendor the same questions so the process and outcome remain fair for all. You’re interviewing these vendors for a very important job – to help your organization advance its mission. Treat them, and the experience, with the necessary respect and rigor.

If you haven’t had demonstrations yet, arrange for scripted demonstrations that focus on your needs, not any new and shiny objects the vendors may wish to show.

After you make a selection, let each vendor know the outcome. You don’t want to leave them hanging and wondering if they should make a call to follow up. Keep in mind that the deal is not sealed until the contract is signed, so use tact when notifying unsuccessful competitors; you never know when you might need to go to “Plan B.” It also helps to provide constructive feedback when possible, so that vendors can bring their best game to the next selection in which they are involved.

The selection process is just one phase in the project cycle, yet it’s a very critical phase. If you don’t select a solution and vendor that meet your requirements, your new technology won’t meet expectations and needs. 

Flickr photo by Mitch Groff

DelCor’s July 2014 Blogger’s Digest & #ASAE14 Preview

(Community, Events, Everything Else) Permanent link

ASAE14 Image Header

ASAE 2014 Annual Meeting & Expo

This weekend, we join thousands of association executives – and you, too, we hope – in Nashville for the annual gathering of the association brain trust. If you’re a conference newbie, be sure to visit The Hive – a lounge designed especially for you to connect with other newbies, ASAE ambassadors, DelCor staff, and mentors/veterans (yes, we “old-timers” are welcome in the lounge, too!) – or to simply find a respite amidst the conference hullabaloo.

Of course, we’re exhibiting, too. You can find us in booth 622 (next to Geico). As part of our ongoing 30 Acts of Appreciation, we’ve created a fun activity to give thanks to Nashville for being great hosts. When you “complete the DelCor meme,” we’ll donate $10 to The Cooks Academy, which helps nourish 1,300 local kids in child care. While you’re there, pick up a copy of our brand-new whitepaper on requirements analysis, or talk to us about any of our 7 areas of service – every one designed to connect you with progress!

Finally, we’ve joined Instagram! We’ll be posting photos of our favorite memes and ASAE activities. Follow us at

For more information on The Hive, newbie tips, DelCor memes, and everything else we’re up to at #ASAE14, visit

Blogger’s Digest: July 2014

Throughout the month, we wrote about requirements, RFPs, RFIs, and how to get the most out of your vendor proposals – all with the aim of designing successful technology projects that propel your organization forward. If you’re heading to #ASAE14 with an RFP in hand, or you’re lining up budget approval for your next big IT project, or you’ll be evaluating exhibitors for a new AMS or other mission-critical system, you just might want to prepare yourself by reading a few of these posts!

And although we’re highlighting last month’s blog posts here, we’d also like to share with you a fun, bonus installment to kick off this month and our countdown to #ASAE14!

Upcoming Events


Want more?

To receive our Blogger’s Digest by email, drop us a note at

Ask the Oracle at DelCor: a request for information (RFI) or a request for proposals (RFP)?

(Project Management) Permanent link

oracle priestess

Selecting a new technology system, application, or software is a daunting task. First, you must first collect, analyze, and document requirements. But, then what? Should you send out an RFP? Or would you find a better vendor or consultant match by sending out an RFI first?

Thankfully, we can rely on the wisdom of the Oracle at DelCor, a distant cousin of the priestess Pythia, the Oracle at Delphi. We eavesdropped on some of the conversations the Oracle had recently with a visitor.

oracle at delphi

“Good afternoon, Oracle. We just got back from a board meeting where the budget for a new AMS was approved. The CEO popped in my office today and told me to send out an RFP immediately. Is that really my next step? Do you have a template?”

No, no, no – no templates!! Do not rush into confusion! Before you send out an RFP, you must be sure that the requirements for the new AMS have been identified and documented. Gather a team of colleague stakeholders, discuss requirements, and review your existing business processes and technology.

The requirements journey can be fraught with peril. Best to bring along a trusted guide. Or read some of our recent posts if you decide to DIY, as they say in your world. Prepare yourself!

After documenting requirements, research the market. Talk to your peers, reach out to other professionals on Collaborate, and check the ASAE Buyers’ Guide. Come back to me when you’ve done your requirements analysis and market research – not before!

[Time passes. The visitor returns.]

“Thank you, Oracle. The requirements analysis process was more beneficial than we expected. We now know what we need – versus what we thought we wanted – and we discovered many business processes that are in need of improvement. Plus, our team is more cohesive because we understand each other’s work and challenges better. We found that as long as we keep our focus on the strategic needs of the association, we are able to make the best decisions.”

Yes, as your mother has said many times, I told you so. The discussions and decisions made during requirements analysis are often as valuable as the solution selected. So, you’ve done your market research, I assume. How many vendors are you considering?

“I have a list of 14. Should I send them an RFP?”

No no no! You will send them an RFI, not an RFP.

“But why an RFI?! My boss specifically said to send an RFP.”

Is your boss as omniscient as I?

[Lightning and thunder strike.]

If you send an RFP out to a dozen vendors, half won’t respond because of your “spray and pray” approach. You must first narrow the field to those who have the appropriate expertise and experience. An RFI will help you do that. Woe be to those who ignore my advice!

[More lightning and thunder.]

oracle storm

[Time passes. The visitor returns.]

“I followed your advice, Oracle. We sent out an RFI and received very helpful responses. Four of the vendors have the experience and expertise we need. Plus, we think their approach to project management, customer service, and support is a good fit for our association. What’s our next step?”

Now, you send an RFP to those 4 vendors.

“Couldn’t you just tell me which one to pick?!”

oracle black cat

[The sky darkens. More thunder and lightning. The visitor takes the hint and runs back to work.]

The end.


Flickr photos by violscraper, Institute for the Study of the Ancient World, Cocabiscuit, Dennis Jarvis

The recipe for a successful RFP

(Project Management) Permanent link

recipe card with measuring cup and spoons

Alfred had never put together a request for proposals (RFP) but he was confident he knew what to do. (After all, he was a good baker! Wait, what does that have to do with it?) Before developing an RFP, he would first do some market research and then send out a request for information (RFI).

He knew better than to blast out an RFP to dozens of vendors. And, he preferred to avoid the nightmare of having to review and compare an excessive number of proposals. Instead, he started with an RFI to narrow the field of candidates to a qualified – and manageable – number. 

After assessing the responses to his RFI, he deduced that 4 firms had the experience, expertise, and approach to customer support that his association needed. In the RFP he sent to the 4 firms, Alfred made an effort to clearly communicate as much as he could about the project so they had the information they needed to prepare an accurate proposal. Because his association had gone through a comprehensive requirements analysis process, the requirements documentation for the project spelled out exactly what they needed. 

His RFP called for 9 ingredients:

  1. RFP selection criteria. Tell the firm why they were chosen to receive the RFP so they have a sense of the criteria you’ve used up to this point. Like a first or second date, you don’t need to reveal all your secrets, but you should let them in on why you’re interested in a third date. What are you looking for in an ideal partner?
  2. Organization description. Provide the basics about your organization: staff and membership size, membership, mission, current technology environment, and any other factors that you think vendors need to know.
  3. Project goals. Explain the strategic context. What problems are you trying to solve with this new technology? Don’t leave out any pertinent history, but don’t write a novel, either.
  4. Project scope. Define the deliverables and requirements as best as you can. Use everything you learned during requirements gathering to craft a clear, concise, and accurate project scope (with the acknowledgement that it might change during the evolution of the project).
  5. Budget range. Vendors want to propose solutions that meet your budgetary expectations. You might only have a general idea of how much you want to spend or how much a particular solution might cost. But you don’t want to hear about a Jaguar if you have a Kia budget! So, at a minimum, you can set the right tone.
  6. Project timeframe. What is the ideal timeframe? Are there any hard deadlines (e.g., were promises made to the board, or are you looking to launch at your annual meeting? [We hope not!]) Any calendar conflicts that will consume your staff’s time? Any dependencies vendor’s should consider?
  7. Requirements documentation. Your requirements could be formatted as a checklist or table according to what’s mandatory, preferred, or optional. This initial triage provides vendors some indication of what is most important to your organization and a framework for telling you how well their offerings can meet your required features and functionality.
  8. Vendor methodology. Find out how the vendor typically manages client relationships and communication. Who will be part of the vendor team? What are their expectations for association staff? What is their approach to development and project management? To get a real response, and not a boilerplate proposal, ask them to provide examples of how their methodology would apply to your situation.
  9. The rules of engagement. Be frank, so vendors can return the favor. What is your decision-making process? How long will it take? Explain the logistics of the selection process so the vendor understands your expectations for phone calls, discussions, and demonstrations. Include the terms of the process (e.g., your right to extend the selection process timeline if need be) to minimize association liabilities.

Cook’s notes:

  • Provide a reasonable deadline for submitting proposals. Vendors will need time to have internal discussions about the proposal and to develop a helpful response.
  • Don’t be tempted to say “no phone calls.” Your team and your prospective vendor partner need the opportunity to evaluate the critical components of a relationship – personal interaction, chemistry, and communication – before any decision is made. Discussions will help you separate the firms that “get you” from those that don’t. Give vendors the opportunity to provide a unique response based on your needs, not their offerings. These conversations may also help you to better define your project scope.

Creating a solid RFP and subsequently engaging in meaningful interaction with prospective partners helps ensure that you receive proposals that will meet your organization’s needs. It should also help you and your team gain valuable insight into your requirements and how the ensuing implementation process will proceed, thus increasing your overall chances of success. And you can celebrate with something you cook up yourself! (Or just order in.)

Flickr photo by liz west

Before you distribute an RFP, narrow down the field with an RFI

(Project Management) Permanent link

Barbara sat with her colleagues in the back of the room exchanging discreet fist bumps. The board had just approved the budget for the new content management system (CMS). After the meeting, the CEO asked her to get a request for proposals (RFP) out as soon as they got back to the office, because the president wants the new system to be up and running before the annual conference. 

A few days later, she looked through the association buyers’ guide and the ads in the latest issue of Associations Now to find CMS vendors and consultants. She found 13 whom she thought might provide CMS implementation; she really wasn’t sure. Then she went logged into the ASAE Collaborate online community to ask for recommendations; she got 8 more names! She sent an RFP to all of them – 21 in total.

The consequences of a buckshot approach to RFPs

Barbara received proposals from 10 firms (about half of those she contacted), none of whom were among those recommended by Collaborate users. Why didn’t those firms respond?

First, several consultants have said on Collaborate that they no longer respond to RFPs like Barbara’s that are sent out with a “cattle call” or “spray and pray” approach. Thoughtful, accurate proposals require a great deal of effort on the vendor’s part; they’re not likely to go after a longshot when the association doesn’t narrow the list down to the most appropriate set of solution providers.

Second, she sent out the RFP without doing a thorough requirements analysis. Vendors didn’t have the information they needed to submit an accurate proposal, and they weren’t supposed to call her, so they didn’t bother.

Here’s what she’ll never know: 3 of the firms who declined to reply would have been a great match for the project. What a missed opportunity for the association – and the vendors!

A wiser approach to market research

You can have a consultant help you with the selection process or you can spend some time on market research. Here’s how we do it. 

After we get to know our client, we use our knowledge of the association technology market to help them pre-select a small field of potential partners. Then the match-making begins.

We introduce the client and a potential vendor to each other with an initial phone call, followed by a demonstration and discussion that’s targeted to the client’s specific needs (not the vendor’s bright and shiny object). The field is narrowed down and some (not necessarily all) of the potential vendors submit nuanced and informed proposals. There’s likely more dialogue and Q&A before a final decision is made and the winning vendor is chosen.

If you don’t have a consultant working with you on your requirements and selection, you need to do your own preliminary market research. Barbara was on the right track with her initial efforts – buyers’ guide, advertisements, Collaborate. But she should have talked to association peers, checked out vendor websites, and done some Googling.

She should have sent out a request for information (RFI).

An RFI doesn’t ask for same depth of information as an RFP, but instead helps to narrow down the field by finding out who has the relevant experience and expertise. You might compare an RFI to an employment ad. You’ll collect a lot of resumes in response to the ad (the RFI), but the real match-making begins when you call in the finalists to discuss their suitability for the job (the RFP). 

What does an organization typically include in an RFI?

  • A description of the project – its context (the “why”), challenges, desired outcomes, and success factors
  • Desired timeline
  • Technological environment – a description of the key systems that must integrate with the desired solution
  • Budget – if the budget is firm and therefore a major consideration

What does a vendor provide in response to an RFI?

  • A description of relevant products and services
  • An overview of experiences with similar institutions, projects, and integrations
  • Their approach to your toughest challenge
  • Customer service and support philosophy/practices
  • Any other critical factors that will help you make your “first cut”

After reviewing the responses to your RFI, the next step is to develop and distribute an RFP to just 3-5 firms. And that’s the topic of our next post!

Dave’s Top 10 Signs Your Project is in Trouble

(AMS, Association Management, Project Management) Permanent link

Top Ten

With apologies to Letterman… 

If any of these signs is familiar to you,
your project is in trouble.

10. Your business analyst is surprised that members have such a large decision-making role regarding the budget. 

Someone doesn’t know how associations work! Bless their heart, as they say in Nashville. Is this consultant going to be the right cultural match for your mission-critical project?

9. Senior staff seem uninterested in the new AMS and refer to it as “the membership database.” 

Uh oh, the CEO needs to get them up to speed quickly. They need education on the big, strategic picture – how the AMS will help the association fulfill its mission. Without senior-level buy-in, participation in requirements gathering, testing, and training will be difficult to obtain from the rest of the staff.

8. The governance director has been handling committee appointments the same way for 20 years and doesn’t intend to change now. 

System implementation provides an opportunity to improve the member experience and staff productivity. Leadership needs to step in and explain that processes may have to change if the association is to take full advantage of new technology. If staff resist change, expensive customization is often necessary, and the same old inefficient processes live on.

 cartoon guy napping under busy sign

7. A department head says his staff is too busy to participate in requirements gathering. 

Without staff input, requirements won’t accurately reflect business needs and the new technology won’t meet expectations. Before the project begins, the project manager must make sure the timeline is reasonable given department obligations, and the CEO must get a promise of cooperation from department heads.

6. A staff working group is in charge of the project. 

No one person has ownership or accountability – that’s big trouble. Everyone should have buy-in, but the buck has to stop somewhere.

5. Only the IT director knows the project plan and timeline. 

If you need the cooperation of staff, you must share the project’s goals, plan, and timeline with them. Otherwise, they won’t be committed. You’ll have trouble getting on their calendars and you’ll likely run into schedule conflicts. 

4. The stressed-out membership director is put in charge of managing the project. 

This is a recipe for failure. Project management takes 50-100% of someone’s time and requires specific skills and experience. Don’t make your staff try to do two full-time jobs.

3. Your colleagues don’t understand why they have to meet with the business analyst. 

If the project goals and expectations were not explained to them, they aren’t going to understand their role in the project. Didn’t anybody work to build a shared vision for this project?

2. There’s money in the budget for the system purchase and implementation – but nothing else. 

Projects are more likely to fail when requirements analysis and project management are short-changed.

drum set

And – drum roll – the number one sign your project is in trouble… 

Everyone, including the CEO, treats the idea of requirements meetings like a root canal. And they’re still wedded to “the way we’ve always done it.” Argh!

Culture starts at the top. Staff won’t see the positives if leadership doesn’t. Don’t move forward until you have the cooperation and commitment you need from your association’s leadership – the CEO and senior staff.

And don’t forget to brush and floss regularly…


Flickr photos, top to bottom, by Billychic, id-iom, and adoephoto

The 6 components of a good requirements analysis process

(AMS, Association Management, Project Management) Permanent link

butterfly metamorphasis

You know that moment in the board meeting when they approve the budget for the new AMS, CMS, or other system you’ve been lobbying for? Yes, that was a beautiful moment – but now it’s time to come down from your high and prepare yourself, your colleagues, and your leadership for the project that lies ahead.

You might think, “I’ve been waiting for this for a long time. I’m ready.” Maybe you feel ready, but is your association ready? Are they prepared for the most critical phase of a technology project – the requirements analysis phase?

Here’s what your association must have in place before starting the requirements analysis (RA) process.

1. Leadership takes ownership of the project.

As the project lead, you own the project, but your CEO and senior staff must behave as if they do, too. They’ve given their blessing to the project; in fact, they helped get approvals from the budget committee and the board. But you are going to need more from leadership if your project is to succeed. 

In the past, technology implementations like new servers or applications were mainly the concern of the IT department. Now, because technology is entwined with everyone’s job, system implementations involve a larger percentage of staff and budget than ever before, and that involvement starts during RA.

Leadership must come to understand how much business analysis, project management, and technical experience and expertise is needed to successfully select and implement new technology. They must be willing to dedicate the appropriate resources to all phases of the project, not just the implementation phase. Hopefully, you kept that in mind when requesting your budget. The RA phase of a project is too often given short shrift, yet that’s the phase that can make or break a project.

2. Staff is fully on board.

The input and buy-in of internal stakeholders is absolutely necessary to ensure project success. A representative of each department or position that will rely on the system must participate in requirements gathering. If stakeholders are left out or don’t dedicate sufficient time to the RA phase, critical functions or processes could be overlooked and the final product won’t fulfill business needs. Staff must also make time to review and approve the requirements documentation so they have a clear understanding of the project’s deliverables and a sense of ownership in the expected outcome – don’t underestimate that last piece!

3. Planners are mindful of departmental calendars.

When planning a project timeline, find out if your project team has responsibilities that must take precedence over the project. 

  • Are conference or education staff in the midst of a busy meeting cycle? 
  • Will staff be consumed with developing budgets for the board? 
  • Will lobbyists be unavailable because of legislative or regulatory hearings?
  • Are membership staff working on a renewal campaign or membership drive?

Coordinate with department heads to make sure staff will be available for the requirements, testing, and training phases of the project. If their participation is to take priority over other tasks, or if duties must be reassigned temporarily, the CEO and senior staff must make that clear from the start. In a tug of war between a project manager and a department head over someone’s time, the project manager will lose every time unless leadership has made it clear what must be done to keep the project on schedule.

4. Everyone gets behind a shared project vision.

Each stakeholder will come to the requirements gathering table with their own departmental agenda – that’s natural – but they must understand how that fits into the bigger picture. Do they understand the project’s goals and how they relate to the association’s strategic goals? You want to make sure the team “gets it.” They need to see the larger, strategic picture – how the new technology will help your association achieve its goals and fulfill its mission. 

5. No one is left in the dark.

Communication starts early with the CEO and senior staff communicating their vision, goals, and expectations for the project to everyone in the organization. Leaders clearly signal to staff that this is an organization-wide project, not a departmental project. You have a plan to keep everyone informed about the project’s progress. And you stick to it – keeping the lights on, so to speak, so no one is left in the dark.

6. Everyone has a positive attitude about change.

Let’s face it – a system implementation is a change management project. During the requirements analysis process, discussion about changes to business processes, workflow, and staff responsibilities can cause conflict, stress, and anxiety. Although it’s not always easy to let go of “the way we’ve always done it,” leadership and staff must resist looking backward so they can help your organization move forward.

Your technology project is more likely to succeed if you take the time to prepare your organization’s leadership and staff for their project roles and if your organization dedicates the appropriate resources up front to collecting and analyzing requirements.

Flickr photo by aussiegall

The unexpected benefits of requirements analysis

(AMS, Association Management, Project Management) Permanent link

insects on coneflowers

You may already know that a technology project is more likely to meet, or even exceed, expectations if you start with a requirements analysis. During this critical phase of a project, the requirements for your new system or application are collected, analyzed, and documented. 

But, did you know that requirements analysis (RA) also has a positive impact on an association’s culture, operations, and staff? We’ve learned from the hundreds of technology projects we’ve managed that the discussions and decisions made during RA are often as valuable as the solution selected.

Lay the foundation for progress

The project team spends hours discussing existing technology and organizational goals, culture, and operations during RA. These conversations often reveal opportunities to streamline, automate, or improve existing business rules and processes. 

When colleagues see the positive impact of these project-related changes, they become less resistant to examining and improving other processes.

For example, prior to implementing a learning management system, many associations restructure their education department’s business processes. After completing that project, an association might turn its attention first to improving related content management processes and then to content workflow processes for their website and digital media.

Once struck, the improvement spark is difficult to snuff out.

Discover new opportunities for increasing productivity and member value

During RA, the positive side of the project balance sheet is revealed. Besides new opportunities for improving productivity, the discussions surrounding requirements can also lead to decisions that positively impact the member experience.

For example, while discussing integration requirements for a new enterprise system, the team realizes they have data in various systems that can be integrated in a way that provides members with new insights about the value of their membership and the organization’s efforts. The integration requirements discussion was the forum and the catalyst that lead the team to realize this potential value proposition. 

Encourage collaboration and shared vision

Staff representing different departments show up for requirements meetings with their own agendas. But then they learn about and begin to understand the goals, needs, and challenges of colleagues in other departments. These discovery sessions offer opportunities for discussion that normally don’t exist in their usual work routines.

RA provides an opportunity for staff to think strategically about the bigger picture – how the new system or business process will help the organization meet its strategic goals. A shared vision for the project replaces their original, department-focused perspective. This new collaborative spirit helps to crumble silos.

Unleash progress

An association’s potential is unleashed during a successful technology implementation when the project team sets aside departmental agendas and works together for the greater good of the project. This potential can be tapped again and again to make further improvements to association operations or to create new membership value. It’s just one side effect of good requirements analysis!

Flickr photo by Robert Müller