Monthly Archives: July 2015

My first Drupal GovCon

by

I went to my first Drupal conference Drupal GovCon, last week. I have been to other conferences, primarily on the vendor side, but this was the first one I went solely as an attendee. Carson (my husband) is an expert in content management systems and has been working with Drupal for quite a while. I have never worked with it, but since we are highlighting it as a core competency of Digital Ambit I thought it was time to get some more exposure. I had 3 goals for the conference: give back to the Drupal community; make some of my own contacts in the Drupal community; and expand my technical knowledge of Drupal.

Unfortunately, I got called to an on-sight client meeting on the first day of Drupal GovCon. I was disappointed to miss Angie Byron‘s (webchick), keynote on Drupal 8. Not only is she iconic in the Drupal community, I’m sure it would have done a bit to lessen the knowledge gap. I had also hoped to catch Forum One’s Drupal 8 for non-developers. That didn’t work out either. It’s a good thing all the sessions were recorded so I can catch up on everything I missed.

I did make it to the opening reception. I met some nice folks from 4Site Studios and reconnected with Sleight-of-Hand Studios. We had some pleasant conversations about the highlights I missed as well as discussing our respective businesses.

Day 2 and 3 started early for me with my volunteer stints at the registration desk. Due to the venue, this was a free event. This resulted in quite a few no-shows, late additions and tickets transfers. There were hiccups, as there are always are, but we worked through them. I met some really passionate organizers who put on a really good event.

The day 2 keynote was a general discussion on open source, including advocates of civiCRM and joomla. The day 3 keynote showcased how Drupal was being used for the NIH 3D print exchange. I did end up making it some sessions, but primarily stayed to the business track. I may have done this because this is the track I feel most comfortable. In retrospect, I probably should have gone to a few more of the technical Drupal ones. Each session was identified as beginner, intermediate or advanced. I had some initial concerns that some of the more technical Drupal sessions were going to be beyond my expertise (having never touched Drupal before). When Carson asked me to attend the intermediate Drupal site auditing session, I found out that those descriptors had more to do with general technology familiarity rather than Drupal itself. With the exception of a few specific Drupal modules, I followed the presentation.

Ultimately, I view the entire experience as a positive one. I learned a few things too.

1) Be confident in my general technical knowledge – As I approach new technologies, I need to remember that I have ~20 years of experience working in and around technology. While I haven’t had my hands in every new software that’s been introduced, I can have the technical knowledge and skills to be able to understand the framework’s and follow the discussion. While I’m not ready to spin up my first Drupal site yet, I feel comfortable that I could  figure it out if I needed to and most definitely could manage a Drupal implementation or migration.

2) Participating in after hours networking is critical – When you attend conferences as a vendor, or simply as an attendee, you have an agenda. There is some list of goals you are trying to fulfill. It may be education, or it may be finding employee candidates or business partners. Regardless, you have limited time to really get to know people during the day. The after hours networking is where you have that extra time to ask more questions, and find more common ground. Having been on the vendor side, I know how much work it is to host those events. Please know that they are worth it and all the attendees appreciate it.

3) Open source is more than the technology, it’s the community – Carson learned this lesson at Drupalcon LA. It was the first time he attended Drupalcon on the side of the business (versus as a developer) and he was really blown away by how open the business leaders were about sharing their processes and KPIs. It’s one thing to hear about it, but it’s another to experience it. NIH provided the venue, but required the event be free. Lots of people gave a lot of time to organize Drupal GovCon. And even more shared their time and expertise to host sessions or run all-day trainings.

4) DC has women in tech – For all that I’ve shared about women in tech, I was really excited to see how many turned out to represent at Drupal GovCon. I believe that there were definitely more than the industry average of ~22% in attendance. Maybe it was the “free” component, but I don’t think so as I have been at other free tech events and not seen the same turn out. Or maybe, it was just that this was an awesome event and they had to be a part of it. Whatever it was, I was happy to see it and be a part of it.

Just take a stand!

by

For as long as I can remember, I’ve been willing to make a decision. The decisions I make are not life or death decisions. I guess this probably makes it easier for me. However, I would say that few people are truly in a position where there decision is going to make a difference between life or death. Yet, I continue to be surprised by people drag out decisions, even the ones that are seemingly insignificant.

Last week I was talking to an independent sales rep for a personal and professional retainer-based service. This service is applicable to many people and is very reasonably priced for individuals, families or small businesses. It also requires no contract, believing that the value of the service will become evident and you will continue on a month to month basis. The sales rep commented about how difficult a decision this was for people.

In another conversation yesterday, I was talking to someone who oversees a team of consultants and project managers. This team is managing a very large number of customers and projects, but often the senior manager has to step in to an escalation situation. For the many of these, he’s is simply reiterating the delivery message around when the work will be started and completed. It became evident in the conversation that the project managers were very hesitant to communicate bad news, or make decisions on prioritizations.

In my customer facing roles, this was never an issue. I understood enough about the business to make a decision, and communicate that decision to both customers and management. I often presented the decision I was going to make, with all the applicable ramifications to management and confirmed their support. I could then effectively manage the communication to the customer. If a customer pushed back on the message, I was able to re-evaluate and re-engage the internal resources to see if any adjustments could be made. At this point, it was helpful to have a senior manager along to show support for the decisions.

The inability to make a decision and move forward is something I see in my teenage daughters as well. For them I suspect it has more to do with confidence than anything else. It is definitely something we are working to take steps to overcome. We talk about decisions (good and bad) and propose other solutions that would have been better. We encourage them to write stories and make little decisions that impact their lives.

When you get presented with that next decision, take a stand. If you can articulate your reasoning when you need to, chances are it will turn out fine. If it turns out that your decision was the best one, then use that knowledge the next time you make a decision. You will only be able to make better decisions by making them. In the broader scheme of things, that one decision will not be significant.

6 Considerations for Making System Migrations Successful

by

Every business makes a system migration decision. The frequency of these decisions has increased significantly, as the improvements to technology are delivered more quickly. Unfortunately, migrations tend to take much longer than everyone wants or thinks. My experience has shown that the following considerations need to be understood and carefully managed to have a successful migration.

  • Why are you migrating?
  • Are there hard dates that apply to the project?
  • How broad is the data or processes you are migrating?
  • How are you controlling the transformation (of data or processes)?
  • How and when are you validating?
  • What are the plans for cutover, training and UAT?

Why are you migrating?

There are always multiple reasons for making a migration decision. Some may be technical like obsolete hardware or degrading software. Other times it may come as result of cost. Regardless of the reason, it is imperative that you also provide business users a reason for the move. This migration will be an inconvenience and they will need to adapt to a new system. You should not do anything that impedes their ability to advocate for the new system. It helps if you can showcase some quick wins by delivering some new business value.

Are there any hard dates that apply to the project?

While this might seem like an obvious question to be asking, it makes a huge difference in project planning. With legacy applications, it is very difficult to plan for every unknown. There tend to be layers of configurations, application upgrades, and varying techniques for implementation and execution (read “spaghetti code”). While all projects should have timelines and deadlines, many times you can build a buffer window in to account for the uncertainty. Ideally, you are planning for future use not just blindly implementing a new system the way it was before. Now is the time to proceed with a fresh set of eyes while still maintaining the insights garnered previously.

How broad is the data or processes you are migrating?

This question tends to raise interesting responses. For all practical purposes, most business users use a finite set of data (year-to-day, 1, 2, 5 years). However, if you pointedly ask a business user what the minimum amount of data they could live with, inevitably the answer will be all of it.  This generally conflicts with how much IT really wants to store or with practical wisdom of data management. Over time, the system has changed, therefore the underlying data has changed.There is a real possibility that early data is of questionable quality and will add no real value for ongoing business use. It may also add some complexities to the implementation process as well. This is also wisdom for most process migrations. Unless you can demonstrate business value of leveraging less data or fewer processes, business users may be wary of the new system.

How are you controlling the transformation?

As mentioned previously, it is recommended to look at a migration from a fresh perspective. Often, this will introduce some requirements to transform the data or process. The application of business rules or assumptions must be fully documented. Additionally, any resultant changes in data or processes identified during the validation stage should be related to those business rules. Make sure the business users embrace the these decisions. If they do not, it will be challenging to get them to engage later in the implementation, or post implementation where critical eyes are determining whether this project is a success.

How and when are you validating?

There are quite a few different steps in the validation process that must occur in a migration. First, there are the basics of making sure your system is implemented and configured to your requirements. More critical is validating that the business use cases return the expected results. Your implementation team should be validating at each step of the way to ensure that issues are quickly identified and resolved.

Validation must occur using methods or interfaces the business users will use. There are general concerns and uncertainty about new systems and being able to provide validated results using agreed upon business processes can go a long way to appease them. Some anomalies are legitimate and they must be fully explained and documented. All sets of tests need to be documented, reviewed during training and UAT and made available to stakeholders in formal documentation or on an internal intranet.

What are the plans for cutover, training and UAT?

Business users need to feel comfortable fulfilling their most basic business needs. If there are nuances or differences on how to accomplish these or in basic assumptions around them, these should be highlighted accordingly. Next, it is helpful for the business users to learn skills that can deliver new business value fairly quickly post-implementation. The goals are to reassure business users that they can still deliver the value they did with the old system, but also that they have new functionality that allows them to deliver new value quickly. This may be as simple as making old value propositions better, faster or more robust.

During this time, the implementation team must quickly respond to questions, issues or concerns. These are the most basic interactions the business users are going to have and will start laying the groundwork for the trust that is required for an implementation to be considered successful. The ultimate goal is for the initial users to fully engage and become advocates across the organization. If these users fulfilled that role with the old system, it will be detrimental to success if that is lost. If these users were not advocates before, it is imperative to win them over.

Isn’t it just data?

by

There is a prevalence of news on “big data”. Almost every day, there is another story about how you can benefit from it. Despite all this, most people do not understand what “big data” means. This has resulted in my complete dislike for this term. Businesses have business questions and data. As businesses grow, they collect more data and the business questions change. This means that different methods are used for storing and managing the data; extracting and cleansing the data; and then analyzing and delivering the  results. Does it really matter if it’s “big?”

“Big data” is often defined by large volume, high velocity and wide variety. There’s no doubt that the increases in volume, velocity and variety of data has introduced new technologies and methodologies. These are not right for all businesses in all circumstances. In order to make the right choice, It is very important for businesses to understand:

  • how much data they have?
  • how quickly their data grows?
  • how much data variety exists?
  • what business questions are they trying to answer?

Once businesses have an understanding of what they have and what they want to accomplish, they can then start focusing on the tools and methodologies for leveraging what they have to get to what they need. Another consideration at this time is determining whether the tools that fit best for today are short term solutions, or whether they will grow with the business as the business needs change.

While I believe that “big data” is an overused term that many don’t really understand, I am a big supporter of businesses becoming more data driven. In order for this to be a success, businesses will need to know what they have, where they are going and what they are looking for. They will also want to evaluate the abundance of data storage, extraction, cleansing and analysis tools to determine which work best for them.