Blog

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!

Home

The DelCor Connection

A facilitator’s tricks of the trade

(Project Management) Permanent link

colored flip chart markers

Not too long ago, I facilitated a 3-day meeting in which a group of 10 independent organizations were working on a project to share information. This group of executives agreed to establish a set of standards for the group that would allow them to share development costs for a software product. We had 2 days to establish a base set of standards to support the needs of the individual organization as well as their community at large. The standards had to include enough detail so that the software development team could propose solutions, but general enough to allow for flexibility during the creative process.

Were we successful? YES!

Why? Preparation, spirit of agreement, and lots of paper!

team in facilitated meeting

Before the team assembled, we established the goals for the workshop. I met with the project manager and business analyst for a full day to prepare each major objective. We developed a series of flip charts with requirements and assumptions from the group. We developed the 4 magic flip charts and assembled all of our supplies!

The team started by reviewing and refining the goals and objectives, agenda, and ground rules. We developed a parking lot and placed it in the room – but off to the side so it was not a distraction.

Here are some specific tricks of the trade that we used to get to success.


Use of color

When you are making decisions, color matters. Why should a good facilitator bring their own stash of markers? Green and blue are the most important colors and therefore are frequently overused and dried out. It’s very difficult to build consensus when you write notes in RED!

  • Black/Brown – Use to label EVERY flip chart. Dark colors make a statement.
  • Blue – Note comments in blue; it is a neutral color.
  • Green – When teams are brainstorming or listing options, all positive options should be noted in GREEN. Each option should be listed with a + [plus sign].
  • Red – When teams are brainstorming or listing options, all negative options should be noted in RED. Each option should be listed with a – [minus sign].
  • Orange/Yellow – Avoid these colors because they are hard to read/differentiate from a distance.


Colored dots

As the team reviewed options, they ranked key items that were critical. They used:

  • red dots to indicate critical,
  • yellow dots to indicate optional, and
  • green dots to indicate the dependency of one item to another.


Sticky notes (aka Post-it®)

Several members of the group needed to think about their needs, so they wrote their ideas on sticky notes. They wrote one idea per note and I added them to the list. During the meeting, people would use sticky notes to add parking lot items to the list during other discussions; they were engaged because they were contributing, but didn’t want to interrupt a good discussion. 

Timer & train whistle

Breaks are critical! Even when people are in the middle of a great discussion, their brains still need to take a break. The facilitator must monitor the agenda and call breaks. The team may wish to renegotiate the break time, but it must be discussed with the group.

It is recommended that the team pick a break time that is not an even number (10, 15 min.). Why? If you schedule a break for 12 minutes, more people return on time! Moreover, deciding the duration of breaks is another opportunity to build agreement.

When the break is almost over, use the train whistle as a sign to return to the room. It’s a lot more effective than trying to yell or herd people.

Keep on writing… keep on writing…

The facilitator must make sure they write everything that is shared by the team. They cannot ignore comments that they deem as unnecessary. Spelling isn’t everything – write as quickly and clearly as possible. As people share information, you can develop a pace by repeating what someone said as you write. This allows the facilitator time to write the information as well as provide feedback to the team member. If there is a long discussion, the facilitator should ask the group to provide a summary or “headline” for the idea.

The facilitator should practice standing and writing so their back is not to the group. Stand with your body facing the group then lean slightly toward the paper.

Fidget toys

Everyone has a hard time staying engaged in long meetings. Use of fidget toys allows people to have a positive outlet for their energy. For tactile members of the team, holding a koosh ball or playing with a fidget toy allows them to focus. Try it!

DelCor Tangle Jr. fidget toys

When are we done?

At the beginning of the meeting, the team defined consensus. They decided that they could live with a solution that was of “B” quality. They may eventually design an “A” solution, but in order to keep things moving, they agreed to start with a solid “B.” Our team followed the agenda, took a lot of breaks and finished the work ON TIME!

Feedback from the group was very good. They said they felt included, were able to share their ideas, and found agreement with their peers. The developers were happy to be included in the discussion so they could understand the context of key discussions while having lots of notes. It served as a great start to the entire project.

chart - data exchange chart - flow chart - profile records

Flickr photo by Royan Lee; meeting and chart photos by author

Getting started with facilitation: setting up for a successful meeting

(Project Management) Permanent link

Lego preparation

When you are assembling resources for a project, don’t overlook the role of a facilitator. When a group or team needs to make decisions, a facilitator is a great resource to lead the meeting to ensure the goals are met.

Facilitator preparation

Before a meeting occurs, the facilitator must meet with the project sponsor and planning team to discuss the goals of the meeting. Then the facilitator will review the room location to ensure it can be set up to maximize participation.

4 magic flip charts that should be part of every meeting

  1. Goals/Objectives – It is critical that the group understand the goals and objectives for the meeting. If there is a series of meetings, there may be overall goals and objectives but each meeting may have more specific goals for each session. >
    facilitator goals chart
  2. Agenda – An agenda helps meeting attendees focus. The agenda should include major milestones and breaks. Start and finish ON TIME! During the introduction of the meeting, make any adjustments suggested by the team. This is step 1 to agreement. Do we ‘agree’ on our agenda?
    facilitator meeting agenda chart
  3. Ground Rules – How will we work together? Don’t assume that everyone shares the same ground rules for a meeting. It is critical that the group review the ground rules together and makes any changes. This is another great point for engagement and agreement. “Do we AGREE on the ground rules?” Ask the team to highlight their favorite ground rule.
    facilitator ground rules chart
  4. Parking Lot – How will we manage issues that are not part of the initial goals and objectives? Don’t forget to include a place to note other items that arise as part of the discussion. It is critical that the facilitator revisit the parking lot at regular times to ensure they are addressed. 

Supplies

Every facilitator should have a kit with critical supplies to help support the meeting. A few favorites are:

  • Flip chart paper
  • Flip chart markers (2 sets)
  • Train whistle
  • Tape
  • Sharpies
  • LOTS of sticky notes
  • A variety of fidget toys
  • Other objects to demonstrate a point
  • Elmo doll
  • Timer
  • Colored dots

Set up the room

Are you ready for your meeting? Do you plan to walk into the conference room and start the meeting? One of the most important elements of a successful meeting is room set-up. Why? If a group needs to have a discussion and have a high level of engagement, the room set-up must support this interaction.

The facilitator should be visible by all. The ideal set-up is small tables arranged in a chevron formation around the facilitator. This allows attendees to see each other as well as the facilitator. It allows them to move around and interact. 

The worst set-up is classroom style where everyone is facing forward and cannot interact with each other. 

Time to get started

Before the meeting begins the facilitator should have the flip charts ready and place sticky notes, Sharpies, and a few fidget toys on each table. If members of the team don’t know each other well, name tents are a must!

The facilitator should welcome everyone to the meeting and review the 4 magic flip charts. During the introduction, it is important that the facilitator build excitement and describe a successful day. To help immediately engage members of the group, the facilitator should ask people to read part of the objectives and agenda. She should ask the group if there are any changes that should be made to the objectives or agenda. Then ask the group if they can agree that the objectives and agenda are correct and move on. 

Next, the facilitator will introduce the ground rules. This is a critical step that allows everyone to discuss how they will work together. It is important to cover emanners (how will we interact with our phones, tablets, etc.?) and vmanners (what about people joining by phone or video?).

Finally, the facilitator should review the purpose and use of the parking lot and ensure that the team understands and agrees with this tool.

By establishing a strong base, the meeting is ready to begin.

Flickr photo by Chris Isherwood; charts by author

Why do I keep yammering on about facilitation?

(Project Management) Permanent link

bubbles in blue sky

Some years ago, I was first introduced to formal facilitation while working on a project at a client site (and I’ve been a promoter ever since – just check out my toolbox). The organization has in internal training program to provide formal project management and facilitation training to staff to strengthen the skills of project teams. I learned many useful tips for being part of a team with a formal facilitator leading a discussion.  

As I have developed my professional skills during my career, the most valuable have been skills to help people communicate with each other. I know this is a big cliché, but it’s true. I decided to take an in-depth course on this practice. I attended The Effective Facilitator course – it is one of the most practical courses I have attended.

What is the difference between a project manager, a business analyst, and a facilitator?

Aren’t they the same?

  • The focus of a facilitator is to help groups come to consensus and agreement. The facilitator does not have a stake in the outcome – simply manage the process for people to work together to find agreement.
  • Business analysts gather requirements for projects, analyze the needs, and develop solutions.
  • Project managers are the conductors who make sure they have a clear direction, the right resources for the project, and keep it moving.

For major projects, it is very helpful to have all three roles to support a project.

What does a facilitator DO?

A facilitator performs many functions – some listed below – that wouldn’t be fair to heap on another team member, especially since facilitators are, by nature and necessity, neutral.

  • Set up the meeting to ensure the group has the best opportunity for a successful meeting
  • Prepare the ground rules, agenda, and goals for the meeting
  • Work with a group to uncover all options
  • Work with a group to build agreement
  • A facilitator stands for the entire meeting (wear comfortable shoes!)
  • They do not contribute content or opinions
  • They write down EXACTLY what is said

WHY do we do this?

We have all been in meetings where a group of people is trying to make a decision and at the end of the meeting nothing is accomplished. It’s exhausting and morale can take a real hit. Everyone feels tired and frustrated and thinks, “Nothing was done and now I have to go to ANOTHER meeting.” 

Facilitators help establish the goals of the meeting and guide the group to a decision. It sounds simple – and it IS with the right training. A trained facilitator will be able to:

  • Accelerate performance 
  • Focus on finding agreement
  • Include a neutral person to lead the meeting
  • Inform, excite, empower and involve staff

Tune in next time when we discuss how YOUR organization can benefit from facilitation.

Flickr photo by Stellajo1976

How to prioritize needs in a technology land of plenty

(Project Management) Permanent link

black cat in a priority mail box

Good enough is no longer good enough when it comes to technology. No matter how much money you’ve invested in technology, your ‘maybe next year’ list continues to grow. Mobile, responsive, social, data analytics, online communities, content management, meeting technology – how do you decide where to invest your limited budget?

As if living in the technology land of plenty wasn’t enough, now everyone is in the buyer’s seat. Technology is no longer a mysterious members-only club behind the closed server room door. We are all technology consumers who can easily purchase technology without including IT staff in the loop because tools and systems are readily available, affordable, and turnkey. 

And that’s a problem.

Read more: Don’t leave IT out of the loop

To keep things running smoothly, and adequately supported, IT staff must be part of technology decisions and implementations.

The power of the IT project portfolio

An IT project portfolio includes all technology initiatives and projects organization-wide, so IT staff can easily spot projects that aren’t aligned with the strategic plan or that lack appropriate resources.

Read more: You have a financial portfolio. Do you have a project portfolio?

Even with a project portfolio, the questions still remains: how do you decide where to invest your limited budget? You need a technology plan – a proactive method for prioritization. A technology plan includes a prioritized list of projects, timelines, and budget estimates.

Read more: Projects gone wild – how to get back on smoother slopes

That’s all well and good, but what if you don’t have a technology plan and you have to make a decision this week about which projects move ahead and which don’t? 

How to establish technology priorities without a technology plan

First, don’t take on any new projects until you develop a list of technology priorities.

Second, review your organization’s strategic plan and goals. You need a solid understanding of organizational priorities to help inform your decisions. Talk to senior staff and department heads about their plans to achieve these goals.

Third, answer these questions: 

  • How does your existing technology assist or hinder progress toward achieving those goals? 
  • Is the technology you already have sufficient for the job?
  • What options exist that will make the job easier? 
  • Can any of those options be used to achieve other goals or support other activities? 
  • How do your existing business processes assist or hinder progress toward achieving those goals?
  • Do you see options for streamlining or improving processes with the help of technology? 

Fourth, meet with senior staff to identify existing, upcoming, and desired projects that involve technology. Are these projects in line with strategic objectives? Does the budget exist to fully support these projects – not only the purchase of the system, but also requirements analysis, project management, initial and ongoing training, maintenance, and upgrades?

The process of technology prioritization

Once you know what’s in the pipeline, you can start dedicating resources to specific projects. Work with executives and a cross-departmental team to prioritize your pain points (technology issues) and projects. Some colleagues may not agree with the results, but they need to be part of the discussion.

Categorize each issue as: 

  1. Critical: The issue is stopping day-to-day business and preventing staff or other stakeholders from accomplishing their work or completing tasks. Examples include technology infrastructure issues.
  2. High: Because a workaround is in place, business can move forward, but it’s painful or time-consuming.
  3. Moderate: The issue doesn’t stop the flow of business but needs to be addressed. Examples include cosmetic issues like adding new fields to the database or streamlining a process. 
  4. Low: The issue needs to be kept on your radar but can wait until you’ve taken care of the more high-priority items on the list.
  5. Wish: The ‘like to have’ but not necessary items.

After you’ve categorized each issue, look only at the list of ‘Critical’ items. Which take the most staff time to fix and cause the most complaints? Mark them as priority #1. Rank these #1 priorities from most to least important. Then continue ranking the remaining priorities on the Critical list.

After you’re done with the Critical items, prioritize and rank the High items in the same way, and then proceed to the other categories.

As you prioritize problems and projects, keep in mind that infrastructure is a critical area that must be addressed first. Then, you can address – in order – data management, website and email, and social media.

What to ask when you’re not sure

Consider these questions as you assign priorities:

  • How will the new technology help the organization achieve one (or more) of its strategic goals?
  • Would the new technology force your organization to change existing business processes? Is that a positive change – for example, will it help improve turn-around or response time, or reduce staff time?
  • Does the technology minimize risk and improve business continuity – for example, preventing security issues or network downtime?
  • How scalable is the new technology?
  • How easily will it integrate with existing technology?
  • What benefits does the technology have in terms of cost savings, access to increased information about members, or other advantages?

Sometimes it’s worthwhile to include a ‘quick win’ or two in the first round of projects. Quick wins are projects that require little investment of time or money, yet they create good will and buy-in by showing that this new collaborative approach to project prioritization is working. 

Prioritization of your organization’s pain points will help you identify the critical and high priority projects that affect your organization’s effectiveness. Remember, project prioritization is a team effort. To keep everyone engaged and invested in the process, share updates with staff on the progress of the project portfolio, particularly the status of their projects, and news about both quick and significant wins.

 

Flickr photo by Nathan Adams

Blogger’s Digest: February 2015

(Everything Else) Permanent link

lion in snow

Frozen

Much like area school systems on countless days this winter, we’re coming to you a bit delayed with our February Blogger’s Digest. So, we bid you an icy welcome to March! Sigh. If you find yourself craving an eternal thaw, here are a few thoughts from our crew during the past month to help you warm up until spring arrives.

Programming note: we’re temporarily retiring our IT Maturity Model Self-Assessment from our website while we contemplate a move to warmer climes. Actually, we’re just upgrading it to give you more insight and to serve you better. In the meantime, if you’re interested in a quick, easy, and free ITMM self-assessment, please contact us today. We think you will be intrigued by what you can learn with just a few simple questions, and once your initial curiosity is satisfied, you might even decide you want more depth and sign on for a complete ITMM assessment by our fabulous team!


Blogger’s Digest: February


Upcoming Events

 

Flickr photo by Mehgan Murphy/Smithsonian's National Zoo

DelCor earns MSP Pioneer 250 award for second consecutive year

(Our Company) Permanent link

Association/nonprofit-focused IT consulting firm recognized for industry-leading managed services

MSP 500 LogoFor the second consecutive year, DelCor Technology Solutions has earned recognition on The Channel Company’s CRN Managed Service Provider (MSP) 500 list as one of the MSP Pioneer 250. This annual list distinguishes the top technology providers and consultants in North America whose leading approach to managed services enables their customers to connect with progress by improving operational efficiencies, eliciting greater value from their IT investments, and leveraging technology to achieve greater competitive advantage.

In today’s world of outsourced IT, the expertise of MSPs like DelCor has become increasingly important to organizations. The plethora of choices in technology can be overwhelming. To facilitate organizations’ selection and adoption of managed services and providers, CRN, the leading media outlet for technology vendors and solution providers, has identified the top 500 MSPs.

This year, CRN’s industry‐focused directory highlights the Top 500 MSPs in three categories, including the Pioneer 250, to which DelCor was named for its success in delivering managed services to small and midsize businesses, namely associations and nonprofits.

“Client satisfaction and referrals are the best gauges of our ability to deliver elite managed services, but this recognition underscores the decades of investment we have made in our staff, operations, and services to the association/nonprofit community,” said Brian Sheehan, DelCor’s Vice President.

Founded in 1984, DelCor has been providing managed IT services since 1990, dedicated Partner support since 2000, and private cloud hosting since 2008. A foundation for all of DelCor’s consulting and network services is its IT Maturity Model, which helps organizations align technology infrastructure and implementation with business goals, so technology complements and support strategy – helping to advance each organization’s mission.

“Technology is an important tool for associations and nonprofits to help them achieve their business objectives, strategic goals, mission, and vision. Our role is to help those organizations select, implement, and support technology wisely – to provide a pathway for success,” continued Sheehan. “Our IT Maturity Model and in-depth IT Maturity Assessments provide a framework for helping organizations align their purchases and processes with strategy.” 

He continued, “Many of today’s technology solutions are just a click away; it’s more important than ever to ensure strategic alignment and efficient IT management.”

“The allure of Everything-as-a-Service to organizations is rooted in the appeal of predictable operational expenses, cost-cutting, resource allocation, and access to on-demand/pay-as-you-go technology. Therein lies a great need for the expertise of managed service providers,” said Robert Faletra, CEO, The Channel Company. “We congratulate the managed service providers who have engineered their businesses to deliver the services their customers rely on for future growth and ongoing success.”

For more information about the MSP500, visit www.CRN.com.

About DelCor

DelCor Technology Solutions, Inc., is an independent technology consulting firm headquartered in Silver Spring, Maryland, with seven areas of service designed especially for associations and nonprofits. Since its founding in 1984, DelCor has helped hundreds of organizations nationwide achieve progress through technology, with a focus on IT Maturity.

About The Channel Company 

The Channel Company, with established brands including CRN, XChange Events, IPED and SharedVue, is the sales channel community’s trusted authority for growth and innovation. For more than three decades, we have leveraged our proven and leading-edge platforms to deliver prescriptive sales and marketing solutions for the technology sales channel. The Channel Company provides Communication, Recruitment, Engagement, Enablement, Demand Generation and Intelligence services to drive technology partnerships. Learn more at www.thechannelcompany.com.

Contact

Bill Walker, Marketing Manager
DelCor Technology Solutions
301.585.4222 ext 144
bwalker @ delcor.com

 

Images: your cure for data indigestion

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

A picture is worth a 1,000 words.

It’s cliché but it’s true. Data visualization is all the rage. People find it helpful to see a visual depiction of information then drill into the details to learn more about the story.

How many reports are sitting on your shelf in a pretty binder (hard copy or electronic)? How often to you refer to them? Did you act on the recommendations of the assessments?

blah blah blah

While I am sure our clients hang on every word we write, a picture helps summarize information and draw attention to important points.

The DelCor IT Maturity Model is a tool that we use on a regular basis when we are preforming technology assessments. 

The model provides the association with a snapshot of how their organization is performing compared to others in association community and helps focus attention on the areas that are most at risk. The model provides a quick view of 4 major areas:

  1. Network/Infrastructure
  2. Data
  3. Online/Digital
  4. Management

Each area is assessed for its maturity

  1. Restrictive
  2. Functional
  3. Effective
  4. Innovative

DelCor IT Maturity Model graphic chart

While this summary is useful to the executive team, it also helps other staff members understand the overall maturity and function of each area of the association IT infrastructure.

Of course it’s difficult to take action on a high-level summary. We layer details related to key functional areas to paint a fuller picture with relevant examples and references that help the association understand how our research and recommendations relate to a specific process or function. For example, while findability is key to a successful website, readability is critical to a report.

If an association is collecting a lot of data but the quality is poor or incomplete, it’s a waste. Volume does not equal quality.

When I am developing a report for a client, I try to break up information so it’s easy to read. In addition, I have to consider the audiences who may read the report and attempt to provide several examples and options for those diverse audiences.

In many cases, we are helping associations develop concepts to build a solid framework so they have a path to maturity. 

The last element I add to as many reports as possible is the ‘so now what do I do?’ section. I help the client prioritize recommendations so the association can develop a plan to act. If an association has several areas that require a lot of work, they may opt to focus on smaller projects, then revisit the larger discussion.

As you may have noticed from many of our blog posts, we love to break things down here at DelCor. In this case, it is all about making the data digestible; there is incredible information in those data, reports, and recommendations – but leadership, staff, and work groups must be able to excavate the actionable nuggets.

Images help – they act like treasure maps. What pictures and other tricks do you use to make data and recommendations understandable and actionable so they don’t die in pretty binders while problems and opportunities lie in wait?

Lego pirate with treasure map

Argh!

 

Lego pirate photo by Fanboy30

It’s agile, not free-for-all development

(Everything Else) Permanent link

free for all sticker

I’m concerned.

The term agile is being used for just about everything: parenting, business operations, personnel management, content marketing. What’s next – wine tasting?

What concerns me is that agile is everyone’s darling, everyone’s savior, the new hope. Help me, Obi Wan! Unfortunately, agile is also easily misunderstood. 

Let’s start at the beginning.

Agile was created by a group of developers in the early 2000s. If you want the quick and dirty on what it’s all about, read their Agile Manifesto to understand the basic underpinnings of this development methodology. It’s not tricky – the developers who wrote the manifesto were tired of delivering systems that didn’t provide value to stakeholders. So, they came up with radical ideas about developing and delivering software that were different than the classic waterfall methodology. 

Here’s a quick refresher on the key differences between waterfall and agile development:

  • In classic waterfall methodology, we stick to a sequence: plan, determine every system requirement, develop, test, deliver, and move into maintenance. Once we’ve completed each project phase, we move on – without looking back. Requirements are fixed once agreed upon; resources and timeline often are modified, but – by design – requirements cannot be.
  • Agile methodology follows a sequence, too, but it’s cyclical, allowing for more iterative development. It’s okay to look back – to tweak and retry something– before plowing ahead. The timeline is fixed, but requirements may be modified based on learnings as the project implementation proceeds.
  • If you want to dive a little deeper into the difference, revisit this old post of mine: agile vs. waterfall 101.


Let’s clear up some misconceptions about agile.

Agile isn’t unstructured.

Agile implementations have structure that requires everyone to know their roles, authority, and accountability in the process. Agile is not a free-for-all development methodology. 

SCRUM is agile, but agile isn’t SCRUM. 

Over the years, different flavors of agile have emerged, each with their own twist on the basic framework laid out by agile’s creators. These include SCRUM, Visualization, RAD, Crystal Clear, and so on.

I frequently hear SCRUM being used as a catch-all phrase for agile. In reality, it’s the other way around: agile is the whole ice cream shop, SCRUM is just one flavor. But it is by no means the only or even the best flavor. However, I will say that SCRUM seems to be the most popular form of agile. 

Agile methodologies have specific language. 

Each flavor has its own language. For example, a few terms specific to SCRUM are: SCRUM Master (sort of like a project manager), daily SCRUMS (15-minute stand-up meetings), user stories (how functional requirements are expressed), and a product backlog (the full list of user stories). 

One of the goals of SCRUM is to keep things moving, so it’s extremely clever to refer to the initial requirements set as a product backlog. It could have just as easily been called product features set or product user story collection. But by using the term backlog, it automatically invokes a feeling of, “We better get going; we already have a backlog!” 

Agile does not mean requirements are wishy washy.

This is the greatest misunderstanding that I would like to clarify. I hear some vendors tell prospects that they use an agile methodology, and then go on to explain one of the benefits is that it allows them to see prototypes and change requirements as the system implementation progresses – that way the client gets exactly what they want. While one flavor of agile does develop this way, most don’t. To make this claim about SCRUM, for example, would be a misstatement. In most flavors of agile, the exact details of the implementation may change, but the user stories (the basis for requirements) give the development team plenty of detail – and those stories don’t change.

Agile requires training for everyone involved. 

Please, please, please – ensure your implementation team AND your organization’s subject matter experts, project managers, leadership team, and everyone else involved with the project have training on how the selected agile methodology will be rolled out. It is a disaster to implement agile without training if your organization typically uses classic waterfall. 

Believe it or not, agile doesn’t guarantee success.

Nor does it guarantee a better quality solution. It’s that simple. Without adequate leadership, stewardship, and resources, any project can blow up into a big mess – no matter what development methodology is used. Agile alone is not necessarily the answer.

Yes, agile allows more iterative development, but that does not automatically mean you will run over budget.

If managed properly, agile can deliver on budget and on time. 

Agile isn’t for everyone, and that’s ok.


After teaching a graduate-level requirements analysis class at Georgetown University for 15 semesters, I have heard plenty of students tell tales of agile failures in their organizations. Your organization must determine for itself whether agile is right for your culture, your skills, and the specific project at hand. 

How do you decide if agile is right for you?


Agile is great when:

  • Decisions can be made quickly and confidently.
  • Subject matter experts are available throughout the project.
  • The entire team is comfortable not knowing every last detail about the solution before it is in the hands of the development or configuration team.

Don’t make any assumptions about agile with respect to whether it is right or wrong for your team or for a particular project. Agile works, but it isn’t foolproof by any means, so go into it fully armed with a clear and thorough understanding. Oh, and don’t get me started on the developers who say they have a “hybrid” approach – I’ll have to save that for another post. 

 

Flickr photo by Vincent Noel

Geek Speak: Reports

(AMS, Association Management) Permanent link

Editor’s Note: Today we launch a new occasional how-to series, Geek Speak. We take complex tasks and topics and break them down into lay language. No longer will geek speak get in your way! The concept and this initial post are the brainchildren of two of our senior consultants, Sarah Manwell and Gretchen Steenstra, both PMPs. Want us to help you get rid of geek speak? Send your nerdy questions to deardel@delcor.com and watch here for an answer!

 

lab report (cartoon drawing)

Creating a useful report specification is one of the most difficult tasks for a project team. A solid report requirement has several key components.

  1. Narrative
    • The narrative section of the report is the written business case and use of the report. This document should include:
      • Audience: Identify who will be using this report on a regular basis. Is this report used by internal staff or external users?
      • Purpose: Describe how the report will be used – will it be a statement to members, graph to Executive Team, analysis, etc.
      • Selection Criteria (GEEK ALERT): Outline the data set that will be included in this report. It is critical that developers understand what data should be included or excluded. Typically this includes information such as: members, active status, exclude inactive members.
      • Parameters: Parameters are options selected by the user to personalize the report. Frequently, parameters are drop down menus and date ranges in the system. (List of Events, Event start and end dates, Publication type)
      • Sort/Group Order: Define how data will be sorted. Will information be grouped by a category? 
      • Fields: List all fields (INCLUDE THE ACTUAL FIELD NAME) that will be displayed on the report. 
      • Output: Define the final format of the report. Will the report be exported into Excel, display results as a graph, etc. 
       
     
  2. Mock Up – draw a picture!
    report mock up (example) 

  3. Work Flow – Create a diagram to define the process. How will users access and run the report? 
    report work flow (example) 

  4. Test Plan – validate the report against the report specifications. A test plan should include the following:
    • Functional: Confirm all functions are operational. Does the report return results, do the drop down menu display info, etc. 
    • Scenario: The subject matter expert outlines common interactions with the system. 
      • The user will run this report for a single meeting between X and Y date. 
      • Another user will run this report for several events
       
    • Validation: Compare report results with expected data. If the database lists 10 registrants for an event, the report should report the same 10 individuals.
    • Exceptions: Develop cases for data that should not be returned in the report. Try to run the report using data that should be excluded.
    • Feedback Loop: The team must decide what process will be used to report feedback. For example, feedback must include all information so a developer can follow the steps a user took to recreate the issue. 
     

Do you have a report-writing horror story or a tip to prevent disaster? Let us know in the comments.

 

Flickr image by Jimmie. Report examples supplied by authors.

 

Blogger’s Digest: December/January

(Everything Else) Permanent link

frost on glass

31, here we come

Throughout 2014, we celebrated and appreciated being a 30-year-old local company. Take a look back at our 30 Acts of Appreciation.

Programming note: we’re switching our publication date to the last day of the month (or thereabouts), rather than the first day of the next. After all, our digest is a “look back” at topics on our minds, and a “look ahead” to when and where we can connect in the near future. As always, if you have suggestions, contact us!


Blogger’s Digest: December/January


Upcoming Events


TECH14 Fodder

December’s Technology Conference at Gaylord National Harbor proved to be a game changer. Attendees witnessed and took part in some real sci-fi type technologies – as well as some provocative discussions. In particular, The Future of AMS Systems, drew a bid crowd and some attention from around the web, including these posts.

 

Flickr photo by Tim