This is all just to say that app-making is nothing like building a house. It’s more like building the first house ever in the history of houses, with a pile of rusty nails and your bare hands, in a non-stop tornado. It’s different every time, and it’s astonishingly complex, non-linear, and unpredictable … The only reason anything ever ships is because people just keep working until it’s ready.

*emphasis mine

And if you have any doubt of the truth of this, just look at software projects that ship on a pre-defined schedule rather than when they are ready.

1. Manage Scope – Keep a Wish List

You want the client to dream, right? Having a place where you can keep things that they would like to do “some day” or brilliant ideas that weren’t in the initial scope will help you keep your project within scope. If you don’t actually complete a project, the client gets no value from it. You spend time upfront scoping the project based on the client’s needs and then the sparks of brilliance can get in the way. So, when that great new idea comes up, the answer can be, “Absolutely! Let’s get that on the list for after we finish developing what we said we’d develop.” Having a Wish List gives you a place to put things that are known to be out of initial scope. Plus, it gives the client a sense of, “Okay, good! This is going to get addressed one day and you heard what I needed.”

Here’s the secret: most of what goes on that list will never get done. The client will either forget what it is when you go back through the list after your project is complete. Or once they starts using the software, they will realize the solution doesn’t need it. But, you’re guaranteeing that what you’re creating ends up having real, lasting value for your client. A happier client will keep coming back to you for more work.

At the end of the project, you can go through the Wish List with your client and include the new requests in the scope for Phase 2 or write a Change Order to address them.

2. Projects Must End! (But What About the Bugs?!)

Let’s face it. When you deliver something to a client, you’re not guaranteeing it for five years, right? If the client finds a bug in five years, you’re not coming in and fixing it for free. It’s custom software; there will be bugs; there will always be bugs.

Part of your sales process needs to address that there will be bugs, how you are going to handle them, and how they get paid for. You can always fix newly found bugs as part of Phase 2 or a Change Order, so you aren’t telling your client they have to live with it forever. But, make sure the client understands that it is part of the process!

Plan to deliver a project based on when testing begins to ensure an end date. Tell your client that they have a certain time to do alpha testing. (Two weeks is a good time period depending on the scope.) Then, you can make some of your magic developer tweaks and fixes, before returning it to the client for two weeks of beta testing. Finally, take it live, possibly with known bugs that you will continue to work on as part of the original scope. Bugs and tweaks found after the timeframe can go to the Wish List.

It is your obligation as a professional to provide a completed project that brings value to your client. If you don’t make them test it by providing a consequence, they won’t do it. And then, they won’t have the value of the completed project. In essence, by forcing this, you are better serving him.

3. Project Manage Your Own Business

Where is your list kept? As a developer, you always have to-do lists for your clients. But, what about the things you need to do to run your business? How do you remember to invoice when you your head is buried in the development that you love?

First step: Stop managing projects via email. Stop the madness now! There are simple-to-use and inexpensive project management solutions out there, like Basecamp, that can be set up to manage your clients’ projects and track communications. You don’t have to insert a bureaucratic process to manage your work better; simply be more deliberate in how you communicate. (If you need assistance on how to set up Basecamp to work best for you and your clients, don’t hesitate to contact me.)

Second step: Don’t manage your business with sticky notes. Add a project into your solution (I call mine Operations.), and add your to-do’s into that project. Most of these types of software will allow you to set dates and reminders. You can even assign a to-do to your subcontractors to submit their timesheets.

4. Avoid Interruptions

Plan your tomorrow before you end today. Check your schedule vs. your to-do list and confirm you have a plan. Then, focus on what you’ve planned to do. You’ll be a lot more efficient, both in not burning your clients’ hours and in getting to completed work.

The only reason you should stop what you’ve planned to do is if the client has an actual emergency. The fact that the client found a typo on one of the layouts is not a reason to stop what you’re doing. You want to train your clients to work in a more efficient way. The benefit to them is that when you have six typos to fix at once, it’s going to cost them the same amount as if you had just fixed one. The benefit to you is you’re not thrown off your plan, and you don’t have to change directions in your mind.

You want to encourage your clients to use your selected project management software properly to report issues and to use email or the phone in an emergency only.

If you proactively change your schedule because you need to think about something else or you’re struggling to solve a problem, actively choose to change directions. However, if you’re reacting to an email or responding to a client call – that’s throwing you off, you have to limit those interruptions. You can close your email; emails don’t disappear if you don’t read them immediately. You can turn off your phone; we’ve had voicemail since at least the 1980s. (And, guess what? I had to do both those things just to write this blog post!)

5. You’re Always Selling

To help you gain better clients and also to keep your schedule more consistent, keep selling, even when you’re booked. Clients who really want to work with you are probably willing to wait a month or more to get started. Work on filling the pipeline so you are better able to pick and choose your clients, resulting in getting to work on projects and with people you like. Create a real sales process. For more details on a sales process development, check out this blog post: Lack of Sales Process Limiting Your Income?

Susan Fennema is the Chaos Eradicating Officer (CEO) of Beyond the Chaos, a consultancy helping small business owners gain control of their lives through better processes, organization, and structure of their business operations and projects. She has over 25 years experience in the software development, creative, marketing, and advertising industries, after receiving her BA in journalism from Texas A&M University. She lives and works in McKinney, Texas, with her husband, her dog, and two cats.

Website: www.beyondthechaos.biz
Twitter: @susanfennema
Facebook: Beyond the Chaos
LinkedIn: Susan Fennema

After months of work, your project is so fabulous that you need more developers. You’ve been using Git as your version control system and creating/merging branches to keep it all straight, but so far it’s just been for personal use. How do you coordinate with others to maintain some semblance of order?

Try the Gitflow Workflow.

Gitflow

Gitflow is a popular way of managing revisions centered around a few basic ideas and actions. It is built into recent version of Git and supported by clients like the free SourceTree and the commercial Tower apps.

You start Gitflow with two main branches, master and develop. These are initialized for you when you activate Gitflow through one of the gui apps or through the command line.

The master branch is never modified directly. It is the code for the currently released version of the app and it is only updated on a new release.

The develop branch is never modified directly either. It starts as a branch of the current master and is updated with changes made in other branches (feature or hotfix, see below). The key here is that the develop branch should always be in a state where it can become the new master at a moment’s notice.

Gitflow is then concerned with the actions that we developers might take. The first common action is to start a “feature”. This feature branch should be appropriately named, e.g., “Addinvoicequerywindow”, and is usually branched off of develop, although it can start from any commit or branch. The developer works in this branch to add and test their code, committing as necessary. Once complete, they “finish” the feature by choosing “Finish” from the Gitflow options. Gitflow merges the feature branch into develop and optionally deletes the branch.

Each developer can have as many simultaneous features as needed and can manually merge one feature branch into another, or cherry pick changes from any other branch.

The next action that a developer might need is a “hotfix”. By starting a hotfix branch, Gitflow will branch off of master, not develop. The purpose of a hotfix is to correct a bug that came up in the currently released version that cannot wait for the next full release. Once a hotfix is “finished”, Gitflow will merge it back into both master and develop. At that point, the new master should be compiled and released.

The final action is the “release”, started after all the needed features have been merged into develop and are ready to be deployed. This is where you can make final changes like updating the version number, release notes, etc. When a release is “finished”, Gitflow will merge it into master and develop, and tag that branch with the version number. After that, the next cycle begins.

In short, you start a feature (or features), make it work, then finish the feature. When all your features are done, start a release, update version numbers, etc., and finish the release. If a bug in the currently deployed version comes to light, start a hotfix, fix the bug, then finish it. By using “start” and “finish” through Gitflow, it handles the appropriate branching, merging, and tagging for you.

For more information, go to the Atlassian site for a good general description and examples (scroll down on the site to read about Gitflow).

This blog post steps through a license owner assigning their Xojo license to an end user.

TL;DR  Go to go your Team pages. End users share their connection key with the license owner, then owner connects with end user’s account by adding that connection key. Now, the owner can assign licenses to anyone they are connected with from their Licenses Page.

Make sure everyone involved already has a Xojo account. If not, create an account.

1. Everyone log in and go to their Team page.

2. The end user gets their connection key and shares it with the license owner.

3. From the Team page, the owner selects “Add Connection” and “Adds” the end user’s connection key. Now the accounts are connected and the license owner will see that end user listed in their Team.

4. Now the license owner can assign their licenses to anyone in their team from their Licenses Page. Select the box next to a license, scroll down to “Assign A License” and choose a name from the drop-down.

Now that the license is assigned, the end user sees it in their Licenses Page, has access to any associated support and special forum channels. The license owner can revoke or extend the license at any time.

Add multiple team members and change who the license is assigned to as needed. If you have questions, contact Xojo Customer Service at hello@xojo.com!