About Patrick Johnson

After joining the Algonquin Studios team as an intern in 2006, I've worked on projects for a vast majority of our clients in one form or another. After earning my degree from SUNY Fredonia in 2008, I joined the team full time and since then have thoroughly enjoyed building relationships both internally and with the great clients that we work together with regularly. Currently as a Development Manager my responsibilities include managing project life cycles from the requirements analysis phase through deployment to supporting production systems. Thanks for reading, go Yankees!

Project Management & Relationships

Very often our blog contributors post great articles about things like managing expectations, solving problems for our clients, and gathering requirements from a client. All of the articles touch on topics that are very relevant to the work we do as consultants every day and one of the key aspects of doing each of these things well and, in turn, being good consultants, is to develop strong relationships with our clients.

Learn About the Key Players

When setting out on a project, one of my goals is to gather the requirements of the software that we’re being engaged to build. Beyond that, we need to understand who the decision makers are. These are often the people that we’ll being dealing with regularly to get things accomplished and make sure the project doesn’t stall due to indecision or missed deliverables. From the smallest task that requires a simple yes/no answer to a very important meeting to discuss a pivotal system process, as Development Managers, we’ll regularly engage the key decision makers to get all the necessary tasks completed.

As part of building a relationship with the parties involved in a project, we’re always trying to understand how our software will help their business. Clear communication is important to any project and we’ll often need to go the extra step of learning the company or industry-specific terminology that our clients use on a day-to-day basis. This helps us understand requests and communicate with each client most effectively.

Another important thing to learn about key parties for a project: what forces are driving their requests, decisions, and actions? From the start, we need to try to find what will make the project run smoothly and what could potentially hold the project back. Key questions here will cover topics like target dates, project budgets, and critical processes. These questions and their answers will help us do exactly what many of our other blog posts talk about–gather requirements, manage expectations, solve problems–all of which are crucial to the success of a project.

Row With, Not Against, the Third-Party Stream

What if your project requires you to work with someone in addition to your client? As a software development team, we regularly find ourselves in situations where we’re required to work with other vendors on tasks like integrating with other systems, adding/modifying code that isn’t ours, or working in an environment that we don’t have control over. These things can present potential hurdles, but we strive to do the best we can to navigate these waters because that’s what will make for the best possible experience and solution for our clients.

Much like when you’re building a relationship with a client, you’ll want to find and engage the key players of any third-party vendor and learn how best to work with them. Some of the best ways to ensure a friendly and professional relationship that meets the needs of your client and their project include:

  1. Asking early and often – If our development team needs something from a third party, whether it be access to a system or knowledge of existing code, we’ll do our best to get ahead by asking questions again and again, as soon as we know we’ll need the assistance.
  2. Understanding that third party teams have schedules, too – People often overlook the fact that other teams are fighting to meet their own deadlines outside of the project you’re working on together. We find the best way to stay on top of external deadlines is to repeatedly ask for tentative completion dates or turn-around timeframes from our co-vendors, so we can align our own goals and expectations and help better manage the goals and expectations of everyone involved in the project.
  3. Smiling – It sounds cheesy, but it can help. If you’re getting resistance from an outside party, do your best to smile when pushing for the answers you need. The best case scenario is that you establish a genuinely friendly relationship with your co-vendor but even if you don’t, getting the answers and info you need in a pleasant manner is always going to make it easier for you to work together successfully. And always remember to keep your client in the loop if you’re waiting for answers or status updates from another vendor.

Does Your Client Look at Your Development Team as a Partner?

As a developer, I often find myself in conversations about how people use applications, even outside of business hours! I frequently get the same feedback from friends/family that I do from new clients–they feel like the people who work in development (or “IT”) abandon them as quickly as possible. In developing good relationships with your client, make an effort to communicate that you’re “with them” on their project. The difference in saying something as minor as “We’ve accomplished” vs “I’ve accomplished” can have a big impact on that feeling. At Algonquin Studios, we take pride in being with our clients and doing the kind of relationship-building work discussed above gives us an extra sense of pride in what we’re able to accomplish. And, we hope that shows in all of our interactions with our clients.


Maintain Your Software Like It’s Your Home

Are you interested in software that runs on a magic PC somewhere in “the cloud,” never has to be bothered with, and always works smoothly? Sure you are, but if you think such a thing sounds too good to be true, you’re right. Keeping an application performing well throughout its life is much like maintaining your own house–it’s necessary and valuable.

In an previous post, I discussed the Software Life Cycle and made some basic comparisons between the preparation needed to build a house and the preparation needed to build software. The parallels don’t end there; a lot of similarities can also be seen in the maintenance of, and care for, both a house and a software system. Unfortunately, once your new home or application is built, you don’t get a free pass to kick back with your feet up and a nice cold beverage in hand. Using the house/software comparison, below I’ve listed a few areas where maintenance is important in both places:

Regular care


  • Regular care at your house will include mowing the lawn, raking the leaves, staining the deck, painting the fence, landscaping, etc. All those things we love to keep busy with! We do them for a reason–to keep our homes looking nice and increase it’s value.
  • Likewise, you should regularly be evaluating how to maintain an aesthetically pleasing and user-friendly experience to keep engagement with your software at its peak. In most cases losing engagement will mean losing value in some way. “Regular maintenance” here can mean generating fresh content regularly, updating the layout of your site, adding accessibility features, or implementing new software standards, where appropriate, to keep your application looking and feeling new.



  • Eventually, and hopefully not before you’re good and ready, your house is going to need a new roof, a refinished driveway, an updated heating/air conditioning system, etc. These are bigger projects and occur less frequently than the weekly, monthly, or yearly tasks mentioned above but these can easily be considered even more important to the general upkeep and maintained value of your home.
  • Your software should be getting upgrades too, as regularly as possible. Regular maintenance times for things like hardware upgrades, software patching, and security updates are a must. Beyond that, you should consider moving your software to the latest versions of code frameworks and database management tools. Staying on old versions of these things, much like failing to replace an old roof, increases susceptibility to leaks. And the longer you wait, the more likely your path to upgrading will be even more painful, more stressful, and more costly.



  • You want to move your laundry room from your first floor into the basement and then remove a wall to expand your dining room? Great…Maybe. Any good contractor will tell you how these changes will affect your house (what if that dining room wall is a load-bearing wall?) and that you’ll need to take these changes into consideration when you think about continued upkeep for your home.
  • Most of your software will have additions after your initial launch, too. This isn’t a bad thing…Much like the laundry room situation above, you won’t always think of everything in your first go-round. How new additions will fit and interact with the rest of your software, and how to most effectively make these additions, should be an important part of maintaining your software. You’ll want to analyze whether new features will cause other parts of your system to have issues, much like how removing a wall from a house may affect its structural integrity. Once your software is live, always consider how system processes interact and what adding a new feature will mean for the people already productively using the software.



  • When you use your basement as a one big storage closet, continuously piling things down there without a periodic clean out, it leads to a huge mess. What happens when you have an emergency and a plumber or HVAC expert needs to get down there and fix something?
  • Even if you haven’t thought about it yet, at some point you’re going to have to clean up your software the same way you would your basement. Today, it’s a brand new system using bleeding-edge technology and state-of-the-art hardware. But as your amazing software ages, all of the data you’re compiling is going to, eventually, become difficult for the system to manage. Do you really need to hang on to a record set of 10,000 emails logged from 1995 anymore? Probably not… So maybe it’s time to archive anything that’s clutter, helping your application breath a little easier. This clean up will help troubleshooting and day-to-day activities go more smoothly, too.

I could keep making house/software upkeep comparisons all day but I think my point has been made: we frequently overlook the maintenance portion of software development but, much like ignoring home maintenance, it’s a bad idea. Take this to heart; regularly scheduled maintenance is incredibly valuable in keeping your software functioning at its best and understanding why and how you need to care for your software will make dealing with it easier in the long run.

Software Development Life Cycle – Listen Up, They’re Not Just Buzzwords

If you’re interested in software development you should be thinking about the Software Development Life Cycle. Whether you have the next great idea for a web site, are a software developer finishing your degree, the owner of a company trying to increase your web presence, or an experienced project manager in the software industry, you may not know it yet but this phrase will have a profound effect on the success of any new or existing software project you’re involved in.

For the purpose of this post, let’s start with defining Software Development Life Cycle (SDLC). A Google search will provide anyone with countless resources on the topic, but for our purposes, we’re talking about the process that takes places from the inception of an idea for software to that idea becoming a fully functional, usable application. In researching the topic you can find most resources suggest an Life Cycle that utilizes phases to break up SDLC into parts. In an effort to be concise, we’ll discuss the following phases:

  1. Requirements Gathering and Analysis

  2. System Architecture and Design

  3. Construction

  4. Quality Assurance

  5. Maintenance

Really what we’re discussing when we say that a software application has a “life” is that it’s constantly growing and evolving to meet its users needs. The phrase “Life Cycle” becomes important when discussing a SDLC because of the evolution of software; the SDLC is the “cycle” of how the software will grow. Every time we create a new iteration of software that life cycle begins again, anew.

Now that we’ve provided a basic definition for SDLC, we can discuss ways to use this information and how it affects software projects. Here are some quick hit ideas to keep in mind:

  • Preparedness

    • Clients should be asking questions about how a prospective software development team is going to be handling their project’s SDLC. Make sure the answers you get are thought out and well-developed. If you were building a house you wouldn’t want to hear “we’ll just throw together four walls and a roof,” right? Become comfortable with the process that you’re about to engage in.

    • Development teams should have an established process in place that they’ve previously executed successfully. When a possible client asks about a specific phase of the SDLC developers should be able to break down how the team is prepared to handle each of the phases.

  • Preference and Communication

    • As a client, think about how life cycles might work best for you and prepare to have that conversation with your development team. But remember to keep in mind that a software team may have years of experience perfecting a great process–be willing to accept their ideas and consider them as options or alternatives.

    • Development teams should have the flexibility to work with clients to meet their needs in the best possible way. Sometimes this might mean prototyping screens throughout the life cycle or doing a large portion of development targeting a “Beta” release for the application.

    • Clear, open communication about how the SDLC will be executed is key in making the project a success. The client and developers should agree, as soon as they can, as to the path they feel will be best.

  • Evolution

    • Both sides need to remember that if a project will have multiple phases, its life cycle will “restart” as you begin a second phase. This means that using everything you have learned along the way in the initial phase(s) will be important to refine requirements for any additions that will be made to the project.

So now we’ve discussed ways that getting to understand the SDLC, even at a basic level, will help both a client and a development team. We’ve only just scratched the surface but, hopefully, you can begin to shape your thoughts about what it might take to build that great new application that will save your company tons of money. The process can’t just be “we’ll slap some code together and, voila!” And the process doesn’t stop here either–the SDLC has many shapes and forms; whether you’re a client or a developer, increasing your knowledge of the Software Development Life Cycle will benefit your team and your software projects, going forward.