We at CURTIS Digital, do a ton of site migrations and this topic of what to do after the switch from domainA.com to domainB.com comes up often. We have put together the following article to walk you through how to handle google webmaster tools for this update.

If you’ve migrated your site to a new domain( from websiteold.com → websitenew.com), use the Change of address tool in Search Console. A change of address will help you manage the transition needed by Google to index your new URLs at the new address, while minimizing impact to your current ranking in Google Search results.

Changing of address will notify Google about the new URLs for your existing content, so that Google can update their index to reflect the new domain for your pages. This updated index status remains in effect for 180 days, by which time Googlebot will have crawled and indexed the pages at the new address.

Things to note before you request an address change

Add  & verify the new domain

• Login to Google Webmaster tool.
• Add a new property or domain. Click the ‘Add a Property’ button and a popup will show up to enter the new website url.

• On the next screen, it will prompt to the verification process. Keep in mind that the  process have different methods. It will depend on how you can verify the domain on your end whatever is more convenient  for you. At this point in time we’ll choose the alternate method ‘HTML tag’. Select ‘Alternate Methods’ tab and click ‘HTML Tag’ option. You will then be able to grab the verification tag to add in to your website. See here for more detailed instruction on how to verify a domain.

• This time, let’s assume we have successfully verified the new domain. Continue on the next step  which is to request the change of Address.

Use the Change of Address tool

Note: This tool is only available in old Search Console

• Select the property or website you want to change

• On the next screen, click the setting gear icon at the right and it will popup a dropdown. Click the ‘Change of Address’ option.

• You will be prompted to add a new domain or select it from the list if you have already added it. This time we’ll add the new domain that we have recently added. Click the ‘New Site’ option. It will prompt the list of all domains available.

• Just choose the new domain that you want to change address in the list.

• Now, follow the on-screen instruction given in the dashboard. Steps 1, 2, 3 should all be mark completed & confirmed. Then click ‘Submit’ to finally request the change of the domain address.  

After one year in the making, Google has finally launched AMP for email to encourage a more interactive, dynamic Gmail user experience. The company announced that it would be supporting AMP for Gmail last year and has been doing the necessary back-end work to successfully launch this new feature.

Welcome to Buying Tech is Hard! In this series, we’ll explore different ways to help ensure you feel empowered during the entire software purchasing cycle. Whether you’re still vetting agencies or about to officially kick off development, working with external vendors can be a roller-coaster of emotions. We want to give you the tools to succeed!

New projects are an exciting time for an organization. They represent the culmination of your teams ideas

Being a manager isn’t easy. Many of our stakeholders are marketing and project managers, and we know how difficult the job can be. Keeping track of everyone else’s work is no small feat, especially when you have an external agency to manage as well. Analyzing dependencies between internal team-members and vendors can quickly grow overwhelming, and in that state of confusion, many people turn toward tools that have brought them clarity before: namely, project plans.

If you search for “Burndown chart example” on Google images, as we software folk are wont to do, you’ll stumble across this little gem

Back in August, we wrote a blog article called “Benefits of Agile: Increased Customer Collaboration” in which we discussed why we loved the communal environment that agile fosters with our clients. That post got us thinking—what other things do we love about Agile? And thus, a blog series was born.

This second installment will be centered on another benefit of Agile that we love: increased risk management. As anyone who’s dabbled in the software industry knows, software can get very expensive very quickly. Risk is inevitable when large amounts of money are involved, but Agile can help alleviate some of the uncertainties inherent in software development.

Incremental Client Releases

One of the cornerstones of Agile is the practice of small, incremental releases. Agile projects run on sprints. Techopedia writer Cory Janssen defines a sprint as a “regular, repeatable work cycle during which work is completed and made ready for review. Generally, sprints are less than 30 days long.” The goal at the end of an Agile sprint is to have a shippable feature (for example, a bug-free purchase flow or account creation flow). This means that, at the very least, the customer will have functioning code at the end of a sprint cycle. As a client, having access to shippable code as soon as possible is imperative.

At CURTIS Digital, we hold a “Sprint Demonstration” meeting with our clients at the end of each sprint to review what work was expected to be completed, what work was actually completed, how we are tracking against our timeline and budget, and then we demo the system to them so they can see their product’s new, completed functionality. This idea might not sound revolutionary, but it means that a product owner has a chance to actually view their system early in the development cycle. In Waterfall, it’s not uncommon for a client to see their product for the first time during the Beta Release, by which point it is essentially completed. A typical Beta review period is hardly enough time to catch all the bugs in a system, let alone leave any room for the client to change their mind. God forbid the project doesn’t actually meet a client’s initial needs—at this point, there is literally (we wish it was figuratively) nothing to do except throw more money at the problem. We’ve said it before, but releasing a product that was built in accordance with outdated requirements to a client is heartbreaking. New software should bring joy, and the hardest part of working at a software agency is delivering a product that is no longer relevant. Unfortunately, it is not uncommon for clients to first realize their requirements were outdated when they see the actual product those requirements spawned. Waterfall methodology offers little room for error and even less room for adjustments.

One unfortunate, dirty-little-secret of the software world is that projects sometimes do get cancelled. This usually happens after thousands of dollars have already been poured into them. As we mentioned above, Agile methodology gives a project owner a clear window into their project, which in turn allows them time to make critical decisions—i.e. are we heading in the right direction, or do we need to shift course? Sadly, the answer to this question is that sometimes the project is no longer necessary for the client’s needs; however, Agile will at least leave them with shippable pieces of code should they decide to resume the project down the road or begin a new endeavor.

Increased Visibility in Timeline Tracking

Another issue with the Waterfall development cycle is that it offers little transparency into how a team is tracking towards their proposed timeline. This is exacerbated by a persistent myth that Waterfall teams can “make up for lost time.” Because work is not divided into sprints in Waterfall, it is often difficult to notice if a project is tracking behind schedule until it is too late to correct the problem. If a development team spends longer on an initial set of requirements than they originally planned, there is an impulse to say “No problem—we can make up for this lost time on other requirements.” Agile touts that lost time is rarely, if ever, reconciled; our personal experiences tend to corroborate this claim. As opposed to several weeks passing before a team realizes the project will be late, Agile employs certain tools that highlight risk almost immediately. Burndown charts are a type of Agile report that tracks how a team is performing daily. That’s right—daily. That means an Agile team can look at a burndown chart at the end of their working day, see how they’re tracking for the current sprint, and know at that moment if they are ahead of schedule, on schedule, or falling behind. This has proven to be a powerful tool for us, because it allows teams to self-diagnose a problem as its happening as opposed to trying to retroactively discern what went wrong. For example, are we ahead of schedule because we over-estimated these tickets? Are we behind schedule because one of our members was out sick yesterday? Having the option to ask these types of questions every day pushes the entire team towards accountability, and it gives management a chance to actually resolve potential issues before the project gets too far along.

Daily Scrum and Sprint Retrospective Meetings

Agile utilizes other tools that foster team accountability and transparency. The biggest of these are the Daily Scrum meeting and the Sprint Retrospective meeting. These meetings are internal meetings (i.e. not client-facing) and are places for agile teams to raise possible red flags to the management’s attention.

The Daily Scrum meeting occurs (you guessed it!) daily, typically in the mornings. Mike Cohen notes that these meetings are under 15 minutes, and they are a time where the team reports the following questions to each other:

1. What did you do yesterday?
2. What will you do today?
3. Are there any impediments in your way?

Answering these questions allows the team to see where the project stands as a whole. Asking about potential impediments is a great way for the management team to learn about possible road blockers that could appear. It is also a good way for the other development team members to offer possible solutions.

The Sprint Retrospective meeting occurs at the end of each sprint. In this meeting, the entire team discusses what went well and what went wrong during the sprint cycle, as well as what the team can do differently during the next sprint to improve. The Sprint Retrospective is a safe place for everyone to raise their concerns and discuss ways to become a more efficient team. It is not meant to be a place to blame or point fingers, and is meant to be a way to encourage comradery between all involved parties.

Conclusion

Having multiple routes to encourage transparency between the development team, the management team, and the customer helps mitigate the opportunity for risks to flourish. We love the scrum meetings that Agile utilizes and have gleaned crucial insights from our sprint burndown charts. Please do not hesitate to reach out to us if you have a question about how agile helps mitigate risk.

Interested in working with us on your next project? Complete the form below.

Let’s get intimate here for a moment and talk about something that software agencies never, ever want to talk about: software billing practices. In our “Do You Love Your Technology Agency?” quiz, the second question asks the user to consider how the numbers look when their agency bills them. For example, do they appear to be precise, or more rounded? The reason this question appears so early in the quiz is because of its importance. Talking about money, just like politics and religion, can be awkward, and dev shops have the tendency to shy away from discussing how their bid amounts are calculated. So, where do these numbers actually come from?

We’ll start at the beginning. Custom software shops (CURTIS Digital included) typically sign two different types of contracts: fixed bid contracts or time and materials contracts. These types of contracts are industry standard. It should come as no surprise that fixed bid contracts are based on a fixed amount of work and money. Under a fixed bid scope of work (SOW), the client and the tech agency mutually agree on a total project cost to complete the requirements regardless of the number of hours actually worked by the vendor. If the tech shop is agile, they will allow their clients to swap out similarly estimated items (in the form of “user stories” instead of requirements). The way this original bid is reached can vary from agency to agency—sometimes it is based on how long a similar project took, sometimes it is a direct reflection of the requirements. At CURTIS Digital, we’ll have our development team estimate how long they think the requirements or user stories will take them to complete, and then we add a percentage of management time to that total to account for meetings, email communications, support, etc. An overall estimate is then delivered to our clients for approval.

Time and Materials (T&M) contracts are based on the actual hours that the agency works billed at some sort of hourly rate. This approach is typically taken if the full requirements of the project are not completely known at the time of project kickoff. In this scenario, we still have our development team estimate all of the requirements and provide our clients with an initial bid with the caveat that, should the requirements change, the client will be billed the actual hours spent. CURTIS Digital will provide our clients with a rate card in our SOW so that they are able to see specific hourly rates for specific roles that we perform (management, client-side development, server-side development, architecture, etc.).

Whether a client signs a fixed bid contract or a T&M contract, software agencies need some way to keep track of hours spend for their projects. CURTIS Digital uses Harvest to keep track of our employee time. Even as I write this blog, I’m tracking time to an “Internal – Social Media” project. Harvest allows us to get down into the nitty-gritty of time tracking. The development team tracks their time to specific tickets that correspond to a user story or requirement. Management tracks their time to meetings, responding to emails, and testing completed development work. Harvest allows us to quickly see how much of our budget we’re using and how quickly we’re using it. This in turn allows us to extrapolate if we’re on track to complete the project on time and within our budget and scope. If we’re not, we can quickly review reports to calculate where we’re spending our time and why. Having a clear outline of the hours spend helps our management team to be the best they can be. If your current agency is not using any internal time tracking, this should be a huge red flag for you. It’s always important to know how many hours are being spent, whether the agency is significantly over or under the estimate.

In addition, just because a software agency knows how many hours they’re spending on a specific project a week doesn’t always mean they’re willing to share that information with their clients. Highlighting a week that went over budget can result in difficult conversations regardless of what type of contract the client signed. That being said, we have always found honesty to be the best policy. In order to foster transparency, we devised a simple weekly report called the Project Status Report (or, more simply, the PSR). CURTIS Digital’s PSRs breaks down the hours spend each week by specific task (architecture, visual design, business analysis, development, management, etc.). The PSR allows our clients to easily keep track of hours spend and see how well their project is performing in terms of schedule, budget, scope, and quality. Regardless if the project is fixed bid, T&M, or maintenance, our clients will receive a PSR.

We’ve discussed how fixed big and T&M projects are billed. Let’s take a moment to review maintenance projects. After a project is completed, our clients usually elect to enter a maintenance agreement. CURTIS Digital maintenance projects are billed as time and materials projects against a retainer. When a client submits a maintenance request, our entire team estimates how long we believe the specific ticket will take to complete in hours. The client then approves or denies this time, and is charged an hourly maintenance rate (for us, $135/hour) to complete it. However, our estimates are not always perfect—sometimes the actual hours spent on tickets fall a little above or below the estimated value (hence being called “estimates”). In this case, we don’t want to charge our clients for blanket hours that didn’t actually get spent, so we go through an internal process called “ticket accounting.” When a team member is working on a specific ticket item, whether it’s actual development time or responding to an email related to the problem, they include the ticket number in the task’s harvest description. Harvest allows us to bulk export all the time tracked to a project, so once a week our team does so and reviews how many hours were spent on each specific ticket. The result is that the client is charged for the exact number of hours the item actually took to complete—no more, no less. That being said, we don’t allow our team to wildly rack up hours on a ticket without approval. A ticket estimated for 2 hours would not get charged for 20. As soon as we encounter any issues that might result in a higher estimate, we go back to our client with both an explanation and a request for additional hours. Typically, tickets will not get billed for more than 20% over on the original estimate without the client’s approval. That means if a ticket was estimated at 2 hours, the most we could bill without additional approval would be 2.40 hours. The PSR shows which tickets were closed each week and what their actual spend was vs. their estimated spend. It also highlights how much of the retainer budget is left.

It goes without saying that building custom software is expensive. We always strive to be fair to both our clients and ourselves, which is why we work so hard to accurately track and report actual hours and budget spend. If none of the practices outlined above sound familiar or if you’re concerned with how your current agency is billing you, it might be time to re-evaluate your current relationship. Be sure to take our “Do You Love Your Technology Agency” quiz to see how they stack up against your expectations.

Interested in working with us on your next project? Complete the form below.

Many first time software buyers don’t know to consider software maintenance when planning their annual budgets. This shortsightedness is understandable—software is expensive to build and most dev shops don’t want to spend a lot of time on long tail cost curves.

An Agile Story can be defined as ” short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system – Mike Cohn”

I found a library a few days ago that has some amazing effects for shadows.