Author Archives: admin

Building Trust

by

Trust is a big component of successful project management. Team resources need to trust that each will will do what he/she has agreed to do, and will do it proficiently. The project owners trust the project manager to effectively manage all the resources, and ensure the project stays on schedule and on budget. The project manager needs to manage trust both up and down the project org structure. Without trust of the project owner, there is uncertainty about the goals, resources and schedule. And without some level of trust of the team resources, the project manager won’t be able to effectively communicate status or have any confidence that the work will get done. Unfortunately, trust is also an area that can be severely lacking in project dynamics.

Let’s first address the trust dynamic between the project manager and the project owner and stakeholders. The stakeholders are those people impacted by the project being delivered. The project owner should be the project’s advocate and supporter within the organization. Lack of trust can manifest itself in several different ways including:

  • stakeholders not trusting the project team to deliver the “right” business solution
  • stakeholders don’t trust that the project team will deliver on time
  • project owner is skeptical of the project success

As project manager, your ultimate success (of the project and within the organization) is dependent on how you manage these concerns. Trust is not something given lightly, it must be earned. If you are working with this project owner and stakeholders for the first time, or had the unfortunate situation of a prior project not going well, you will need to assume there are gaps in trust. Once you recognize this as a challenge, you can take the necessary steps to move forward. These should include:

  • understanding the business objectives and challenges the project is supposed to resolve.
    • ask to sit with the business users and share their problem. This deep understanding will help the team deliver the right solution.
  • as much communication as required by the project owner and stakeholders to make them feel included (and informed).
    • Ex: weekly email statuses or twice weekly status calls; or a couple of in depth show and tell sessions. It will really depend on the organization and the specific stakeholders.
    • communicating setbacks or challenges.  Do not shy away from sharing, or feel you need to hide the negative. Doing so will negatively impact project perception, and is counter to the trust you are trying to build.
  • using agile methodologies to deliver functionally ready project components iteratively through the project timeline that you can show the stakeholders.

Next up is the trust dynamic between the project team members (resources and project manager). Again, there can be many reasons why trust is non-existent within the team. Some include:

  • New project manager or team members that have never worked together before.
  • One or more team members have previously demonstrated some undesirable traits (ie. not delivering, not communicating delays, etc).

The team members do not have to like each other, although that can help. The project manager’s goal is to foster enough mutual respect to trust that the work will get done, and  the right project solution gets delivered to the stakeholders. A few methods for doing this include:

  • holding regular project touchbase calls.
    • these can be daily standups, or twice a week status calls. Figure out what works for you and your team.
  • having team members share information about external activities and families.
    • This helps team members see how similar they are, and lets them see the passion and interests that drives each of them.
  • providing time for peer programming or “cardboard batman” sessions.
    • By allowing the team members to help each other, they build deeper connections and foster trust. It makes the project a team effort, not just isolated, individual work.
  • Setting clear expectations, then verifying them.
    • It’s important to provide as much information as you have at the time you have it. Requirements are more fluid than we all care to admit, but making sure you pass new information on quickly will help with trust.
    • As project manager, do your best to verify the work delivered. This may be internal qa or show and tell with the stakeholders.
  • Acknowledging mistakes and promoting successes.
    • People want to do a good job. They also enjoy when those details gets shared within the organization. The project manager needs to take time to promote the team members.
    • Mistakes happen. They can significantly impact the project so they can’t be ignored. More important than the actual mistake is figuring out how to fix it. Acknowledge it, and then find a solution to get it remedied.

There are many different skills that make you an effective project manager. All of them are for not, if you can’t build the trust you need among the team. I challenge you to take a hard look at your projects and make sure you are taking the necessary steps to build the trust you need to make the project, and your team successful.

Teaching data science to my teenage daughter

by

Note: This post is a bit long, but it’s the story behind the evolution of our project to teach data analytics and data science to a teenager, leveraging her love of ice hockey.

There are a few times during my career where I have made decisions, that were in retrospect, a lot better for my family than I initially thought. At the time I made the decision, I did weigh the impact of the decision on my family, but there have been 2 that were really the best things that could have happened. The first was back in 2011 when I quit my job. My younger daughter was struggling in school and having the time and flexibility to get her the help she needed would have been extremely difficult if I had been working the schedule I had been. The second happened recently. In March I left another job to join my husband in the full-time running of our business. Since March, I’ve been able to spend one-on-one time with each of my daughters, taking separate spring break trips. And more importantly (at least for this post), I was able to work with Cayla, our 16 year old, during her summer internship project.

This story begins when we decided in the spring that we were going to hire Cayla as an intern in Digital Ambit, our software and data integration consulting business. At the time we knew we wanted to use this time productively, specifically we hoped to teach Cayla some technical skills. The most obvious route would have been to have Carson teach her programming. However, Carson was more than 100% utilized in our consulting business, where I had a bit more available time working on the business. We needed to be able to get Cayla some tech skills, without severely impacting Carson’s ability to deliver on our billable work. This left me to figure something out.

My background is fairly diverse, with time spent in both technical and software skills. I consider myself a technical project manager, truly leveraging my technical skills to manage customers and projects. While I can manage any technical project or implementation, my actual technical experience focuses on databases and data management. I had recently taken some data science Coursera courses and had dipped my toe in the R world. I finally decided Cayla was going to do a data analytics/science project to take hockey statistics and see if she could predict who will win next year’s Stanley Cup.

I bought Cayla a couple of books on data science for business and practical data science with R. I knew Cayla had never studied statistics and had a few concerns about the complexity of resources written about data science and R. I made Cayla write a blog to make sure she could articulate the material she was learning. Once she started picking up some of the basics, we talked through the project at a very high level so Cayla knew what the next steps were. This was very much a hands on project for her. She had to find the data, download the data, cleanse the data, and figure out the R syntax to load and analyze the data. I gave her space to work through issues, especially after the first few times she told me she had an issue with R and after asking if she had confirmed the syntax, pointing out the missing comma or syntax error.

We were about a month into the project before Cayla could bring all the pieces together and really explain what she was trying to do. She could relate the daily work to the project, and had mapped out her next steps to align to her business question (“Who will win the next Stanley Cup?”). At this same time, we learned we had been accepted to present this story to the DC Web Women Code(Her) conference. This intensified the pressure, and added a hard deadline of September 12, 2015.

This is where it got a bit difficult for Cayla. At this point she had gotten all the data she thought she needed, cleansed it (or so she thought), and had found  at least one way to calculate the historical means, and populate the 2015-2016 statistics. The complex nature of the statistical models and the applicable documentation caused this to be a real sticking point for Cayla. Unfortunately, the method she had been using, along with her still dirty data made reproducibility and data modeling extremely difficult.

At this point, I stepped in to help in a more hands on way. I knew that I wanted to create an R script to share during our presentation, so I started walking through Cayla’s syntax. Sometimes things that work in isolation, don’t work the best when combined with the other methods you applied. It took some intense focus to step through the process, cleanse the data to acceptable R processing standards, and leveraging different syntax for historical means and filling gaps. The hardest part was finding clear, concise examples of people who had done this before. Ultimately, I was able to find syntax that worked to run models against the data and analyze the data. We were not successful in getting the model to predict any winners.

I think Cayla and I both learned a lot from this project. Cayla learned that she can do really hard things, she’s never done before. Cayla also learned about planning and organizing data projects, and how truly difficult, but incredibly important, it is to clean your data. I learned that Cayla can learn anything with the right incentive, or within the framework of something that interests her. I also learned that in data analytics and science, more people need to publish their work in simpler forms. Please don’t assume everyone has a PHD.

We presented our story at the Code(Her) conference on Saturday. Cayla reinforced her knowledge of data science during the Intro to Machine Learning session, and seemed to have fun learning agile principles while playing games. The day culminated with us presenting to a room full of women. It was really rewarding to see how well Cayla did, and to see how many wanted to hear us.

IMG_0396

To see our detailed presentation and additional materials, visit my github page.

3 steps to take when your project isn’t going well

by

In an ideal world, all our projects are on-time and under budget. The reality is that is rarely the case. More often, a project runs over on budget or timeline. For the nature of this blog, I’m not going to go into all the reasons why there can be budget or timeline overages. I want to focus on techniques for managing the impact. These very much tie into my approach to project management (you can learn more in this post).

  1. Communicate – At the first sign of a problem, starting communicating up and down the project chain. You want to make sure the project team are aware of the additional stress and constraints the stakeholders are feeling. This keeps them moving towards the end, but prepares them for some of the more difficult conversations they may have with stakeholders. Also important is having an honest conversation with your stakeholders and business sponsors. You need to make sure that everyone is on the same page. It is not about point blame, but rather collectively determining the next steps and discussing remediation options. This might include reducing the scope, or increasing resources or budget.
  2. Be positive about your successes – When projects take a turn for the worst, it is easy to dwell on what’s going on, focusing solely on how to fix it. Make sure you are positive about the successes. These may be as simple as just developing the use cases, or maybe the team has started implementation and development. Each moment of time spent on the project increases the project outputs, and creates positive moments. Leverage these to keep morale up and keep stakeholders engaged with what has been accomplished. It helps if you’ve split your project into small, incremental releases. It’s harder, but still possible when your project has more nebulous intermittent releases.
  3. Keep team moving towards some release date – Project crunch mode is a very stressful time for all those involved. When those culminate, you will want the team to regroup to determine what can be delivered in the shortest amount of time. Ideally, this has some, if not all, of the functionality that is most critical to the business users. You are always better off if you get something in the hands of the business users, as quickly as you can.

Murphy’s law definitely exists in project management. If it can happen, it probably will at some point. I find that it’s much easier to manage these rough times if I communicate (almost to the point of over-communication), be positive about the small successes the team has and make sure we have a plan to deliver something. It helps if the things you deliver are aligned to the stakeholder’s critical requirements. Most importantly, do not shy away from talking about your project issues. That just builds resentment and further uncertainty.

My Approach to Project Management

by

A couple of weeks ago, the project sponsor of a project I’m working on sent a really nice note in reference to my work. It said “Dagny knows her stuff and I like her approach.” Since then I’ve been really thinking about my “approach.” I know that I’m good at what I do, and in this case, I’ve been given the flexibility to run these projects my way. But still, I wonder what defines my approach.

In the end, I’ve come up with 3 core principles to my approach.

  1.  Questions, Questions, Questions – It is critical in any project you manage to be willing and able to ask as many questions as you need. This starts before you even take on the project in it’s entirety. Who are my resources? Are they dedicated or part-time to the project? Next is the deep dive into any specifications or other project documentation. What are the goals? What is being requested by the customer? What do the resources think it means? What does the development landscape look at? All of these are just to get you started. Once you manage the projects, it is still your responsibility to ask and push. This is the only way to understand what’s going on. It is also the only way to can effectively keep the stakeholders up to date, as well as truly be able to remove roadblocks for the resources.
  2. Communication – Once you dive in and ask all these questions, it’s equally important to document the answers and communicate the impact. This applies as much (if not more) to negative information as positive. Do not shy away from delivering bad news. Knowledge in an of itself is worthless. You need to make sure you are effectively aggregating, documenting and then communicating the information you find. Make it available. Your forthrightness will be appreciated.
  3. Oversight – I believe you need to check in with your resources and your stakeholders on a regular basis. A regular cadence of status meetings is recommended, but I would strongly consider subsequent email statuses delivered between meetings, especially for time sensitive/critical projects.

I think these 3 principles are at the heart of my project management methodology. They result in not just effective management of a project, but also help to build the trust you need with resources and stakeholders.

Don’t take for granted how far you’ve come

by

I’m inspired to write this by my 16 year old daughter, who is also our summer intern. I’ve written about her before so I won’t spend too much time on background info. Cayla will start her junior year of high school in about two weeks, and this is Cayla’s first job. She agreed to do it because she had nothing else to do. My husband and I definitely had high hopes for her. Not only did we want her to start developing skills she would need after high school, we also hoped that she would start developing an interest in technology, aside from just personal use. She’s spent the last two months helping consolidate and organize our marketing list; started on Node School; and started learning R so she could work on her data science project to predict who will win the next Stanley Cup. Cayla also started pulling the data she needs for her project and working through her project plan.

Throughout all this, I’ve been amazed by the basic skills in business (and business applications), data management, and project management that I take for granted. There have been ample opportunities this summer for me to realize how far I’ve come since I started my first professional job.

Basic Skills in Business Applications – My experience is all very business and analytics intensive. As part of that, I’m very familiar with vlookups (using one data element in one spreadsheet to dynamically find the data element in another spreadsheet), pivot tables, advance sorting and grouping. While it made sense to make sure to teach Cayla how to do vlookups and pivot tables (as needed), it never crossed my mind that we would need to show her how to sort by multiple columns. Or, that she could use Excel functions to find duplicates, or convert names to the same format using the split text function plus a formula to reformat them. After the first time Cayla spent 5 hours adding the same value to multiple records by copying the cell and paste over and over again, it was very clear that I needed to be more explicit in the instructions and guidance I gave. These are basic lessons that I didn’t even realize everyone didn’t know.

Data Management – Cayla has been working with downloading, cleansing and analyzing NHL statistics for the last couple of weeks. We have had several discussions around computers being stupid and doing exactly you tell them to do. When the computer displays duplicate records, instead of grouping by a single identifier, I am quick to recognize that something is different about the records. Cayla was always more inclined to say that nothing was different as she was looking at the superficial value of the player name. Once she started diving into the data, she found spaces, tick marks and commas that wreaked havoc on her data analysis.

Project Management – I know that everyone works differently, but I’m a huge believer in documentation. I’m an avid notetaker, in my handy dandy hardcopy, spiral bound notebook. I red ink (and blue and green…) spec documents, log detailed questions and explanations and am quick to make sure everyone involved gets the information. I don’t believe in hoarding information. I assumed this was a way of life. It’s really not. No matter how many times I have coached Cayla about clearly documenting her project work, or outlining her blog post, this is not intuitive or comfortable to her. I’m a firm believer that developing these skills will help her feel more organized, help her remember or reference information better and would make communication in whatever form, easier for her.

Each of these are just a small subset of the examples I encountered this summer mentoring and leading Cayla. As we continue to mentor and sponsor people, we need to remember how far we have come. Let’s take a step back and make sure we convey the information required for people to learn the critical skills we have. They may not retain them all, but the good ones will definitely adapt some of those skills as their own.

7 Principles of Relationships

by

I had the opportunity to see Rita Goodroe (@ritagoodroe), business and relationship coach, speak on “Relationships Drive Success” at the Community Business Partnership (CBP) First Friday event. I attended the event because CBP puts on good events and I hadn’t done much networking in a couple of weeks. I was not familiar with Mrs. Goodroe and was a tad concerned about the direction this topic could take. Mrs. Goodroe had great energy, and gave very practical and down to earth advice. A major theme revolved around action so I thought I would share Mrs. Goodroe’s 7 principles on relationships and share their application to my life.

Before I dive into the 7 principles, let’s review relationships. We all have a pretty instinctive understanding of when they go really wrong, but we don’t generally think of what makes really good ones. Great relationships are ones where you can relax. You don’t work too hard, you don’t overthink it. You enjoy it and thrive in it. That said, do you associate relationships with things other than people? Mrs. Goodroe points out our relationships we have with money, time, yourself, business as well as those you have with others. I would say some of those relationships are even stronger than the ones you have with others.

Now that I left you with that food for thought, we can dive into the 7 principles of relationships.

1. Mindset is everything – Thoughts lead to feelings which lead to actions which lead to results. Make sure you have thoughts that lead to actions. At the end of the day, it’s the curse of the self-fulfilling prophecy. If you didn’t get a good night’s sleep and wake up grumpy, you may see the grumpiness in everything. This might be as simple as seeing the overcast, low 80-degree weather as another reason to bring sadness to your day. It could be that the last 10 days were over 100 degrees and this overcast cool day was a perfect break.

I have quite 3 professional jobs since I graduate from college. One in 2001, one in 2011 and one in 2015. Some might argue that it was wise to quit the first two at the time I did given we were in the middle of the dotcom bust and a recession. For me, it was never a concern. I always knew that I would land on my feet and find a new opportunity. The alternative of staying in positions or with companies that wasn’t the right fit and suffering through my own unhappiness seemed so much more daunting and unreasonable.

2. Know your value, know your worth – It’s pretty common to underestimate your own value and worth. Unfortunately, if you act in a way that does not demonstrate your value or worth, you will probably end in a situation where you are unhappy. This might be you negotiating on rates and ending up with the wrong client. If you are not confident, the people you interact with will know and will treat you respectively.

In the late 1990s I was approached by a family friend to work at a dotcom startup. He offered me $8/hour. I was already waitressing and had another internship on Capitol Hill making $10/hour. This additional job just didn’t make any sense for me unless I was making at least $10/hour. I knew the value that was able to bring and knew what made logical sense for me at the time. The family friend was a bit put off by my initial push-back but has since hired me multiple times and become a long-time mentor. Had I accepted the lower hourly rate, I would have been frustrated and probably would have ultimately quit the lowest paying job I had at the time.

3. Establish boundaries and don’t compromise – I think we all have heard this one quite a bit, but I think as woman it can be very difficult to adhere to. As humans, we all want to be wanted so when we get approached with any offer, it’s hard to take a step back to think about it, before immediately just accepting it. If you compromise your principles and let your boundaries be trampled, you will always be at the whim of someone else. You need to stay true to your goals.

My family has a busy life. My husband and I run a consulting business, so I’m managing day to day operations and out networking while he is the primary billable resource. Time is money for him. This means he has to choose his extracurricular activities very carefully. I then must also pick up the slack for cooking dinner, shopping, and transporting our kids to their myriad of activities including karate, ice hockey and soccer. I am also active in a Women in Technology professional organization and sit on the board of the WIT Education Foundation. But I know my boundaries. I do not volunteer as team mom on any of our kids’ teams as I believe we fulfill our contribution with my husband as coach. Additionally, when I’m approached about other volunteer opportunities, I gracefully decline.

4. Put yourself out their more – Networking and “free education based marketing” are two really useful means for building your business. Speak, blog, participate in communities and meet new people. It’s important to approach these opportunities with your eyes open and thinking about how you add value for others. The more you provide to others, the more it will come back to you (eventually).

This one is hard for me. I’m definitely an introvert and need to rejuvenate alone with a book after each in person networking event. It’s something I work on everyday. While I have been on LinkedIn and have grown my connections there, I was never a big contributor. I only joined Twitter and Facebook in 2012. I did it for a purpose. Actually there were 2: figure out what it was all about and put myself out their for 2 projects I was working on – a women in tech job fair and a food blog. While I’m not as active on my food blog, I did start contributing on this one. I don’t know too many followers, but am working on building a community.

5. Make it about them, not you – You already know all there is to know about you, so spend your time learning about them. It doesn’t have to be business related. Ask about the last book they read or vacation they took. You learn a lot more about the person you are talking to, and do more to build a real connection than you would if you only asked about their business and only looked for useful tips for yourself.

Again, this is one that I’m still working on. It’s not asking the initial question, but continuing the conversation on or transitioning off that don’t come as smooth for me. I will say that some of my most unlikely friends came from having interactions that had nothing to do with business. It might be the older neighbor down the street, or the parents of the child at the daycare who just happens to be your daughter’s exact age and now 16 years later is still considered her oldest friend. If it was all about me, then these relationships probably wouldn’t have happened.

6. Don’t be attached to the outcome – This is very much about perspective. If you are constantly worried that someone won’t like you or aren’t looking for the common ground, then your outcome is probably pretty precarious. If you change your thinking a bit and ask the question “why did this person cross my path?”, you might just be surprised by the answer.

Since I quit my prior job in March to pursue my business full-time, I have been taking a broader view of networking. I’ve tried several new events and approached them with an open mind. While not all the formats were right for me, I did end up meeting interesting people at all of them. I’ve convinced myself that I just need to pull on my big girl pants and go talk to some new people.

7. Every “no” brings you closer to “yes” – As you approach new or difficult situations, look for the lesson or contribution. It’s important here to look at both what you did well, but also what you can improve on. What can I do differently to get a different outcome?

Ultimately, this is the culmination of the 6 principles. If you approach life with a positive mindset, know your value & worth so you can set boundaries while putting yourself out there more, focusing on the people you meet (and how you can help them), but no becoming attached to the outcome, you will be one step closer to your goal.

Every time I’ve met someone for lunch or coffee, or attended a new networking event, I’ve stayed true to the fact that regardless of the outcome of any discussions, I’ve taken our business one step closer to where it needs to be. In the course of conversation, people have asked about me and I’ve been able to share what we are doing. They may not need those services, or there may not be a long-term connection with the people I met, but it is one more person who knows what we are doing. We are just starting out, so exposure is as important as any thing else we are doing.

As Mrs. Goodroe reminded us all on Friday, I will remind you today: It is not enough to have just read this post. You must take action. Stop saying “you can’t” (i.e. I can’t…because I don’t have any time). Recognize how your actions impact your goals. If you don’t like what you see, then change it.

Agile and #ILookLikeAnEngineer and the perception of things

by

I’m struck this week by the perception of things. This is not an unusual state for me as often I’m perceived as something different than what I am. My husband often tells people he is married to a West Indian woman. This creates some startling responses when those same people meet me for the first time. The general assumption is that I’m a black woman, so when they are presented with a blue eyed, blonde, very pale white woman, there is a bit of confusion. In addition, I am also 5’4 tall and average sized with an exercise of choice is Kempo (karate) and have earned my second degree black belt. Just another example of conflicting perception versus reality.

As a technical project manager, I am always interested in learning about new techniques and methodologies so like most of us, am familiar with Agile Development methodologies. It strikes me as interesting that many people and organizations will say “they do agile.” Agile is an adjective defined by Merriam Webster as “able to move quickly and easily” or ” having a quick resourceful and adaptable character.” How does one then “do agile?” I understand employing some specific components of agile methodologies, or working towards becoming agile. Organizations would be a whole lot better off if they stopped worrying about doing agile and actually started working towards becoming agile.

This week I was struck but yet another campaign about women in tech and what it means to be an engineer. These types of conversations always frustrate me a bit. I fully consider myself a women in technology, regardless of the fact that I’ve approached it from a business perspective. I’m raising two daughters, one who is very interested and one who doesn’t know she’s interested yet. “An engineer” or “to engineer” all relate to skillful or clever delivery of plans. While I will not minimize the effort it takes to obtain a engineering degree, the engineering mindset is definitely more than a degree.

I did participate in the #ILookLikeAnEngineer campaign, posting photos of both my daughters today. My youngest is very crafty, often coming up with elaborate stories for dolls and creating amazing worlds in Minecraft (parkour courses, stables with fancy armor, and star trek doors to her fancy chateaus). She also is learning to program so she can create games and websites on the topics she likes. We’ve been spending the summer tinkering with old laptops, assembling wooden model skulls and have plans for making cheese, soap, roominate assembly and arduino programming.

IMG_0175

As I have written about before, my older daughter sits on the periphery of STEM. While she has never expressed an interest in learning to program, or really anything mom and dad were doing. That said, when we proposed a summer internship working for her parents’ consulting company; learning about programming, social media (for business) and using “big data” techniques and software to predict who wins next year’s stanley cup, she accepted the challenge with open eyes.

IMG_0231

All of these are indicative of a larger problem. To make assumptions based on first impressions is harmful to us all. It is within our best interest to approach each situation with an open mind. Be observant; see what the reality looks like, hear what is being said, and then make your assessment.

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.