by Guest | Mar 7, 2019 | sponsor, Community, Development
By Joe Flynn, Senior Manager, Technical Architecture at Insight
A huge part of technology, especially how it affects business, is an exercise in fear.
Remember when IT pros were reluctant to move basic Office 365 to the cloud? Or when it felt absurd to think about workers answering emails on airplanes? Augmented reality in the workplace? Yeah, right.
Metaphorically, in that big ocean of a technological change, there’s an appeal for businesses to ride the waves. But doing so is hard, and each wave seems to be more daunting than the last.
Modern IT management is a big wave
The IT industry has been moving toward a more unified approach to IT management for some time now. Modern IT management is about consolidating tools that embrace cloud centricity and make life easier for IT — whether that’s with provisioning, patch management, pushing out applications and anything in between.
The move to the cloud is on. This infographic breaks down 21 stats on cloud adoption — and gives 7 best practices for migrating.
Many of the clients I work with use a big jumble of toolsets. They may image a machine and manage it with a toolset meant only for that device. For another device, they use another toolset. One tool for anti-virus. Another for encryption. It’s a very fragmented environment.
When fragmentation is all you know and nothing breaks down completely — and you use numerous resources to maintain that environment — the risk of adopting something new might feel scary.
Unfortunately, fear isn’t sustainable in the IT industry (if you’re not willing to face it head-on).
Because technology forces change, and companies are becoming tech companies at heart, we’re all being nudged down a different path.
An eye-opening tech report: The 2018 Insight Intelligent Technology Index surveyed IT decision-makers to understand the impact of tech on business. See the findings.
I’ve found that companies addressing their fear of change experience a catharsis of sorts. Based on conversations I’ve had with clients, they’re coming to these realizations:
1. The efficiency gains are remarkable.
I once had a client who told me it took five hours to image one machine. Don’t get me wrong, the process was clearly defined. The machine would go to one group that would throw the image on, another group to set it up for users and then a third group to help users transfer all of their data. But with the evolution of technology to a cloud provisioning model, it just doesn’t make sense to spend that much time and resources on such an inefficient process.
2. Fragmentation is costly.
This notion goes back to management toolsets. Although the saying goes, “If it ain’t broke, don’t fix it,” our clients are finding it’s a short-sighted view. Outside of licensing costs, the operational costs associated with supporting an increasing number of devices, dealing with maintenance windows and everything under the sun are really starting to weigh down financially on the business.
The 6 pillars of modern IT: Insight Chief Information Officer Mike Guggemos breaks down what IT pros need to master to drive meaningful change in this podcast.
3. It’s a journey, not a leap.
Many clients aren’t fully ready to release what they have on-premises to the cloud. That’s okay. We know there are limitations with legacy apps and deployment, and some things will simply have to stay on-premises — for now. As tech inevitably evolves, more companies will make the shift to the cloud. An encouraging way to think about it is that modern IT management is still in its infancy — businesses may be behind that curve, but we’re all evolving here.
4. We’re all moving in the same direction.
Take it from Brad Anderson, corporate vice president of Microsoft, who Tweeted some reassuring social proof stats on Microsoft Enterprise Mobility + Security (EMS):
As of July 7, 2018, EMS has 85,000 customers (a 13,000 increase in 90 days alone) and 82 million active licenses in the EMS stack (up 55% in 90 days). This growth is huge, but mostly, it’s reassuring that businesses are moving toward cloud-based management.
I believe fear can lead to all kinds of positive change. Fear makes people hesitant, but think of it this way: The more hesitant an organization is to ride the big wave of change, the more time it has to think things through, build a strategy and have some great epiphanies along the way.
For additional content around the Top 8 IT Challenges, go here.
About Joe Flynn
Senior Manager, Technical Architecture at Insight
With more than 20 years of industry experience, Joe focuses on the Microsoft stack of technologies to help clients keep up with the workplace technology curve. His expertise revolves around the latest cloud tools that drive collaboration, communication and security.
by Guest | Feb 14, 2019 | Development, sponsor
Developing technology is one of the most challenging endeavors a person can embark on, and unless you’ve actually coded software, it’s difficult to understand the complexities involved- even for some developers!
To get a better idea of how non-developers can better screen developers for projects, our team at PHX SUW asked Vincent Serpico, founder of SerpicoDEV, to share some tips for finding the right development team for your project.
Success and failure in development projects have patterns that can help foresee these outcomes, for better or for worse. There are several key measures, if implemented, that can ensure the success of a project. These are best determined by asking the following 10 questions of the development company before starting a project.
1. What experience do you have in my domain?
The more your development team understands your business, the better they can create and implement your project. But, your development team is unlikely to have expertise in every aspect of the business. After all, there are a lot of verticals out there.
It is appropriate to expect your development team to take the time to research and understand your ideal client, your market, and your business model. They should ask you questions; they should read articles and listen to podcasts on your industry and topic; they should spend some time on-site with you. In many ways, they should become stand-in “experts” in your field, specifically for your niche in your industry. This will closely inform the user experience, and ensure the desired business outcome can be met with the intended software use.
2. How do you plan projects?
You know what they say, “months of coding will save you days of planning…” While some companies will answer this question by saying “we are lean and agile” and try to move on. But that’s often just an excuse not to take the time to plan in detail up-front what a project will entail — and thereby also reduce any corrective measures that may occur later.
Project planning means taking the time to think through the project in a detailed way that will serve the project management process. It means walking through the flow and usability of a project before developers begin to code. It means creating a solid plan and a roadmap to the final outcome, knowing that a plan can be modified in the process. The plan can then become the guideline to keep a project on target for delivery — and manage costs. Those days planning? In the end, they save months of coding and wasted time and money.
3. What documentation will I get from you?
Development documentation comes in several forms. There are flow diagrams, wireframes, mockups, and project plans (assuming, of course, your development team took the time to plan your project). There are user guides, test scripts, and deployment guides, to name a few more.
First, if your development team is not creating all of these documents, you need to find out why. The creation of these documents ensures that a project follows a measurable process. Second, if you decide to switch development teams or take your development in-house, these documents will serve well to ensure a smooth transition. Always be sure there is documentation of the project.
Also important is documentation within the code itself. Too many times development teams don’t provide proper comments within the code. A great way to see if they’re going to provide good comments/documentation is to ask yourself, are they good communicators? Ask to see some of their code and have a third party audit it if you don’t feel comfortable auditing it yourself. But who audits the auditors? That’s a separate blog post.
4. What is the team structure?
There are a lot of different team structures. Certainly, there is no one “right” team structure. It really depends on the project. The purpose of this question is to ensure that your development team has: a) thoroughly thought through the optimal team for you — not underpowered and overstaffed; and b) to ensure there is leadership and accountability inherent in the team’s structure. A solid team may include a project manager, a development team lead or architect, two developers, a designer, and a tester.
5. What transparency do I have in the team’s daily activities?
This is a big one. Never ever work with a development company that does not provide 100 percent transparency into your development team’s activities. It’s your money, it’s your team, it’s your project. You should have full access to each team member’s daily activities, and preferably on a granular level. You should have the ability to speak with any team member anytime you need to. “Black box” development teams typically squander your time and money, and this can be avoided with 100 percent transparency.
Obviously, you’re not there to micromanage, no one likes that, but you are trying to integrate their team with yours to ensure proper development of the product.
6. Why did you choose this technology stack?
We are fortunate to live in a time when there are many great technologies available from which to choose. The list of technology stacks that you can utilize to implement your project could easily fit an entire page. And while a lot of different technologies can get the job done, there’s a good way to narrow down your choice of technology stack.
First, you need to research how many other developers know the technology stack. For example, Julia is a great programming language for numerical analysis. So is Python. However, there are far more Python developers than Julia developers. So, if you need to switch teams or bring on more developers, you’ll have a wider pool of talent with Python developers than Julia developers.
Second, steer clear of brand-new development stacks. Besides the problem of lack of resources, new development stacks are not proven… and your project should not serve as the proving ground!
Other considerations to keep in mind when considering technology stacks:
•What is the average cost for developers in the stack you are using?
•What is the cost to deploy the stack on servers?
•What documentation is available on the stack?
•Do they have use cases of other projects using the stack?
7. What is your testing strategy?
Testers generally get treated as second-class citizens in the development culture. The truth is testing is a vital and crucial element to the development process. Good testing involves creating a wide array of test scripts that will QA your project from every angle, including edge cases. This is a lot more complex than it sounds.
When founders take on testing themselves, they often miss wide swatches of bugs that made it into production. A trained QA tester knows where to find these buried bugs. Be sure your development team has a very solid testing strategy in place and that the testing strategy is a key part of the development process. Avoid teams that do not treat testers as first-class members of their team.
8. What is your coding and delivery strategy?
There are too many buzzwords when it comes to coding. Agile, waterfall, spiral, lean, and so many more. The buzzword is not important. In fact, ignore it. Instead, ask probing questions about “how” your development team codes. In what ways does the team communicate with each other? How often does the team communicate with each other? Who is the team leader? How are tasks planned and assigned? How often are deliveries targeted? How does the team handle bugs and problems? What is the team’s policy in testing (before a trained QA tester tests)? How does the team handle differences of opinion? What do the team members do if they become late on delivery? If your development company simply replies, “Don’t worry. We’re agile.” you can reply, “You’re fired!” You deserve to know how your development team works.
9. How often can we meet for status updates?
Unfortunately, too many clients come out of development relationships that take advantage of their time and resources. I have seen development shops go days and sometimes weeks without answering phone calls or emails — leaving a client worried, stressed, anxious, and frustrated. Your development team should be providing you with regular status updates.
And your development team should be meeting with you regularly. How often is “meeting regularly?” That question can be answered with where you are in your project lifecycle and what level of detail you need. It can be as frequently as every day, or bi-weekly, or once every two weeks. “Regularly” means meeting at intervals that make you, as the client and owner of the project, comfortable.
“Regularly” means meeting at intervals that ensure you feel you have all the details you need. As the project and business owner, you have the power to determine how often you meet.
10. How will you support my project once it’s delivered?
Any experienced entrepreneur will tell you that deploying your project is just the beginning. In other words, that’s when the really hard work starts: Business Execution! And while you are running around wearing the multiple hats of lead generation, marketing, PR, sales, accounting, legal, management, employee HR, payroll, and everything else, you will also need to deal with maintenance and updates to your software.
How will your development team handle urgent updates? When you need a new feature added quickly to drive revenue, or a small bug fixed that’s annoying a high-profile client, how will your development team address the request? Will you be treated with a sense of urgency, or will your request fall to the bottom of the queue? Of course, you should be treated with a sense of urgency, regardless of the type of request. Ensure there is a mechanism in place for your development team to address all of your post-deployment requests in a timely manner.
But that’s just a start…
While these ten questions are a good start you will probably have some of your own questions: What about pricing and invoicing policies? Access and ownership of your code? A good development shop will answer your questions and empower you to achieve your software goal. Any development team that does less doesn’t deserve your trust…or your business.
It’s your development team’s responsibility to provide you with world-class service and treat you like a valued partner. It’s your responsibility to do your due diligence before starting a development relationship. Be sure to ask these ten questions to every development team you interview. If you are currently in a development relationship that isn’t working, ask these probing questions to better determine if the partnership is the right kind of match. It’s your money, your code, and your project. The success of your project is highly correlated to processes, methodology, and culture built into the development team you hire.
Ready to learn more about best practices in software development?
Check out Ready to Launch: An Entrepreneurs Guide to Developing Software On-Time and In-Budget
SerpicoDEV builds software for entrepreneurs, startups, and small businesses. They have been in business for 10 years, have a team of 25 people, and have supported more than 100 businesses to expand and prosper. Contact SerpicoDEV to learn more about our development process.
Vincent Serpico is also a long-time member of the PHX tech community and an active investor in tech companies bringing innovation to the industry. He’s founded a few tech companies and raised money himself. Most recently Vincent founded SerpicoDEV with a single mission: Enthusiastically and expertly build great software for entrepreneurs, start-ups and software companies.