About Progile: As one of the leading Project Management Staff Augmentation, PMO Consulting, And Project Management Training firm in the US, we always keep our pulse on industry's' trends and innovations. By leveraging our deep industry expertise, we are able to bring froth the best consultants and solutions for our clients' needs.
Cloud technology projects seemingly bring a host of promises implicit on first blush, promises which make most high-level managers and executives positively drool with excitement. Environments that are ready to go out of the box, no physical racks of servers to maintain, overall development time for new software cut by up to 2/3, and an unstated stipulation of more developers and engineers available to support your platform of choice (due to it being a “hot” technology) are all extremely tempting notion. However, there’s more than a few areas where promise and reality live in a fluid Venn diagram where they only partially intersect. For the Project Manager overseeing the whole lovely mess, this means time, complications, and risk galore which you had a better plan for before you end up looking like a deer-in-a-headlight. Assuming you’re a seasoned pro at managing projects and reasonably comfortable in the tech world, here’s three areas to pay special attention to, so you can ask the right questions before signing up for something your team can’t deliver.
Setup, Interaction of Platform Complications, and Security
Let’s begin with the obvious problem, especially on the enterprise level. Very few platforms coexist perfectly out of the box. It’s not possible to just have an engineer switch on a platform, migrate information, set up logins, slap your corporate logo up on the login page, and turn users loose. Customization is implicit in the adoption of any new platform.
Likely, there will be interactions from existing platforms to various services, which requires development effort to function. For example, if you’re using Amazon Web Services to house your database, you’ll need to adapt the database to their particular restrictions. Even if you’re using a supposedly cloud-friendly database like MarkLogic, it’s not a painless setup. Understanding the effort involved for your DevOps team is imperative, since it translates directly into time, a dependency for other planned work, and, of course, your overall spend.
Abstractly speaking, making X database talk to Y application might seem simple, but it is seldom straightforward. Inevitably there are protocols for connection, which might be complicated by security concerns. Many organizations insist on a connecting API or additional layer in place to ensure faster transfer of info and thwart possible breaches, which require more dev and testing. In addition, the vast majority of enterprise organizations will require extensive security reviews and compliance, which you’ll need to factor into your delivery date.
The Understanding Gap
It might sound obvious, but expertise matters. I point this out because oftentimes it isn’t adequately represented in discussions with decision makers—not anybody’s “fault,” per se, just a product of the system. In general, Directors and C-Level execs make a decision on which next-generation platform is going to phase out the legacy system currently in use by consulting a Subject Matter Expert and absorbing pitches from pre-sales folks. They later then make their determination based on price and surface-level functionalities. Once the technology is selected, it’s handed down to the project and engineering level for implementation. Unfortunately, it is when the rubber hits the road, the project team starts to realize the effort needed to adopt the solution organization-wide. This is the time to lean on your experts, and push back to establish your team’s needs around reasonable delivery.
I’ll elaborate this an example—I’ve done numerous projects in the ETL (Extract, Tranform, Load) world, and one of my favorite products is Informatica. It’s powerful, slick, beautifully designed, and connects well with Salesforce, which is, of course, slowly taking over the world. Informatica pre-sales once sold a firm I consulted for a solution, but didn’t elaborate on some of the key differences between their different database extraction technologies—one, being real-time, was far more difficult to institute than the intermittent database transfer technology, in that it required a lot more custom coding of the services which transferred that data to Salesforce. Thus, due to minimal SME interaction, stakeholders handed us a delivery date sold to their client of approximately 45 days for a project which realistically needed a minimum of three to four months to complete. The end result was a lot of delivering of bad news, managing expectations, and late nights spent reworking multiple plans, punctuated by meetings with emotional personalities. Thankfully, we somehow pulled it all off, but it was definitely an anxiety-inducing few months.
The Skill Gap
This dovetails nicely with my previous point, but may actually be even more vital. Even the best PM is just a conductor of the orchestra—in other words, you’re only as good as the people on your team. Unfortunately, if they fail, you get the blame, instead of the credit.
The bad news in this area is twofold: resume “inflation” is becoming more common nowadays, as certain less scrupulous tech pros have figured out representing themselves as having five years experience instead of two in some technology will command them a salary premium. Second, many times a recruiter or hiring manager may not ask the right questions in the rush to get someone working on this urgent position—not their fault, since they don’t really know the technology, and the competition for tech pros is so stiff nowadays there’s an urgency to get people hired by yesterday if they have the skills we need. But the impact of hiring the wrong fit can be notable and have a cascading effect.
A developer with less time in a given technology is, by nature, greener than the more experienced person. While the dev with two years is Googling an issue, checking stack overflow, or messaging his colleagues to “take a look at this for me,” the dev with eight years under his belt has likely already seen this multiple times, probably already knows how to fix it instinctively, and likely has a GitHub full of pre-formed code snippets they can snap in to help speed up the delivery timeline. Too many times I’ve seen solutions not work properly when demoed (either not at all or incredibly slow and clunky), only to have an experienced dev come into the picture and immediately point out a development structure and overall set of dependencies which are not in line with best practices. So while your budget may be happier hiring two junior devs for $35/hr versus the one senior for $75/hr, simple economics come into play here. If a junior takes four weeks to complete a feature set that a senior would have taken half the time to do, you’ve technically saved $400 ($5,600 vs. 6,000), though there are likely other operational and cost impacts as you almost certainly have dependencies and other teams/team members waiting for this particular piece of work. On the other hand (and this is extremely likely), if you’re forced to have your senior dev rework the junior’s work for one week, you’ve now ballooned that cost to $8,400 and thrown your timeline off by an even larger amount. Delays cost money, so oftentimes a little more investment in your team is better.
The practical solution here is simple: screen, screen, screen. If you are part of the hiring process, always hold a technical interview, with no exceptions. I often ask to be a part of any technical interviews and kick it off with some softball questions. If you don’t know much about the technology they’ll be specializing in, read a few articles and forums beforehand, and take a few notes for basic areas you can ask them about. Make sure your technical architects and best engineering minds are controlling the conversation, and let them tell you if they think the person is up to your company’s standards. Oftentimes your SMEs will understand the daily scope of the job better than anyone else involved, saving you the hassle and the worry down the road. Once your team looks good, your job automatically becomes at least 50% easier.
About The Author: Bio: Morgan Reed is a veteran Technical Project Manager and Scrum Master, with a background in Software Development and Testing. He resides in Phoenix, Arizona with his family and a house full of dogs.