Executing the Plans
Ensuring Timeline, Quality, & Budget and Handling Changes
There are countless possibilities through the life of a project, and regardless of the effort and attention given to planning, many of those possibilities will inevitably fall through. Some can be opportunities, but most of them are usually undesirable. It is of paramount importance that we identify these potential “outliers” at the earliest possible time to give ourselves the largest amount of time to put our failsafes into action.
We have a good plan, and we aim to stick with it. This is why we go one step beyond the milestones that you and your project’s stakeholders are interested in, and create finer checkpoints to measure our team’s progress against. These checkpoints are created based on our collective experience and expertise on the tasks involved, delineated on logical and/or logistical basis. Depending on the desired velocity of the project and the methodology of the approach, our point-of-contact (POC) on your project will communicate at reasonable intervals with the project managers and team leads to assess the continued soundness of each planned checkpoints. All of this will be transparent to you and will not place additional burden on your organization. Of course, if something does start to deviate, our POC will definitely loop you in and keep you updated.
An optimized team might not always stay optimized throughout a project. Team members can have unplanned absences and some might become burnt out. We will constantly monitor the human aspect of your project, and address any fluctuations in personnel optimization before they become problems. We conduct regular 1-on-1s with everyone on the team to assess if their interests have changed and/or if the nature of the tasks they have been working on has changed. This is critical to our operations, because a dissatisfied team member will eventually lead to a reduction in efficiency and project velocity. There are things beyond anyone’s control; but for those within our control, we will work hard to keep your project team happy.
It is the job of a project manager to keep tabs on the health of a project. But is it only the job of a project manager? We are not satisfied with the traditional passive way of managing projects. Here at BLT, we put extraordinary emphasis on cultivating an active mentality of independence, dependability, and knowing when something can spin out of control. When we recruit new talent, we specifically test their ability to call out issues as they are, without reservations. Once they become a part of the BLT family, they are further trained on how to precisely and concisely communicate issues and their severeness. Over the past decade, we have fostered a corporate culture that oversees every single one of our project from both top and bottom, making early detection of issues a cornerstone of our identity. This is BLT.
Our project managers are the pilots, empowered with the authority to guide deviating projects back on track. However, there are times when higher directions are necessary. This is where our project managers shine: They are selected in a significant part due to their ability to fully understand the directions and caveats, and communicate everything to everyone they oversee without distortion. Purity in communication is the backbone to maneuvering a team as a single cohesive unit towards a single objective. We train our project managers not only in the technologies they will be dealing with, but also in critical thinking, so they can ask the right questions when their technological competence falls short. This is why we place our trust in our project managers.
At BLT, we strive to maintain a culture of “disciplined fluidity.” While our top-down hierarchy possesses the rigidity needed for disciplined project executions, we have a flat structure for a fluid feedback path. Everyone from all levels of our organization is encouraged to directly submit their feedback on our operations vertically to the POC of their project, or laterally to other POC-level members of BLT for an impartial review. We have structured it this way to avoid the classic “pigeonholing” and to encourage the free flow of ideas, frustrations, and everything else in between. This allows us to be more proactive on both opportunities and potential pitfalls. BLT was built on the principle of efficiency, and this is how we maintain it.
We have both spent a significant amount of time and attention to iron out all the details to make your project a success as planned, but changes to the original plan will always happen. Small changes are easy to accommodate. It’s the large ones that needs care. There are two general directions from which the need for significant alterations come: A change in business needs, and a change forced by an unforeseen issue. How well such alterations can be accommodated depends on how late in the project we are, how much budget can be allocated to the change, etc. However, one thing is certain: We will work closely with you to make sure that: You are given an accurate idea of the scale of the change; The change is logistically mitigated to cause only necessary disruptions, and nothing more; You are quickly informed of any part of the change that needs to be scaled back; The overall effects of the change on the project timeline is communicated to you as accurately as possible; and You will always have the final say on whether to proceed.
One of the most critical milestones of a project is the deployment, and nearly all projects have multiple deployments or even more. It is critical not because of the change in audience from developers to stakeholders, or stakeholders to real users; rather, it is due to the change in environment. For reasons of cost, privacy, dependencies, and whatever else, the development environment is nearly always different from the testing environment, which in turn is inevitably different from the production environment. We recognize this and have field-proven plans in place to cover pre-deployment checks, deployment, and post-deployment support to handle all issues that might come up due to the differences in environments. We can ensure that, no matter when something happens with a deployment, you will always have someone to speak to, even if it is 3am when you discovered the problem.
A completed project is rarely “done.” Projects are ongoing endeavors that need maintenance to stay optimal and support to stay relevant. Whether it’s software updates, enhancement patches, or anything in between, we have you covered. As a project passes the “deployment-complete” milestone, we would automatically wind down the team to minimize your costs. However, this does not mean your team is gone: You will still have access to many of the key team members for an agreed-upon period of time to cover bugs and routine updates. We also have a “long term evolution” process to help you reobtain your original team members for more elaborate changes, and to mitigate any changes in personnel that may have occurred during the downtime.
No matter what your project is, there will always be a time when it has reached the end of its designed lifespan, or your organization has decided to move on to a different technology, or you would like another vendor to take over. Whatever the reason might be, we are prepared to make this transition as smoothly for you as possible. Let’s take a look together next on how everything we have done up to this point has been carefully designed to make this happen!