Develpreneur: Become a Better Developer and Entrepreneur

When we complete a project for a customer or employer, we give them a product. Thus, there is a form of deliverable packaging that we need to consider for that hand-off. This concept may be confusing, but it is not complicated. You do not need to shrinkwrap a box with a USB drive in it or anything like that. Instead, we are focused on documentation, scripts, and how you hand over the final product. The Simple Stuff When your deliverables are source code or a single document, then little packaging is needed. It is either the file sent via email or committed to source control. No installation is required. However, you should provide comments or some sort of notes, so the recipient understands what they are getting. There is no real packaging to be concerned about. Just review and verify the deliverable. An extra step and quality check can avoid embarrassing corrections. The Common Stuff The more typical situation is where a deliverable is a lengthy document, several files, and there is an opportunity to provide an "unboxing" experience. You are not likely to reach the level of an Apple product or something high end like that. However, you can get close. When you hand over source code, provide deliverable packaging that you would want. This package includes an easy-to-handle bundle like a compressed (zip) file. Provide instructions for how to use the documents. If some configuration is required, then include instructions on how to do so. Include a packaging list just like any physically boxed product. They should easily be able to determine what they received. When you are providing a lengthy document, it should be easy to read. Use formatting and white space as we discussed in the quality of deliverables. Also, provide a cover page, outline, and reference section as needed. In the end, deliverable packaging is your first impression. The better the impression, the more a customer is pleased. Do not pass up this chance to add value to your work. Learn more in the book written for Develpreneurs at any stage in their progress: https://www.amazon.com/Source-Code-Happiness-Finding-Success-ebook/dp/B07MKZBF6R

Sooner or later, every developer is asked for project deliverables. This may be source code, binary files, or full-blown documents. No matter which of these is required, the best approach is to make sure these are complete. Thus, let's look at some guidelines, suggestions, and best practices to help you nail this part of your job. Follow The Instructions First and foremost, follow directions. We should have learned this in grade school. Just as in those educational exercises, project deliverables should directly come from the requirements. Do not add deliverables unless they are implied. More importantly, do not skip on any of the project deliverables. The best way to look at these is to see them as what you will be graded on. Just like any other assignment, you can knock part of the deliverables out of the park. However, anything that is missing will blot out those great successes. For example, you could build me the most fabulous car ever and skip the wheels. How happy do you think I would be with that car? Attention To Detail The expectation of the project deliverables is that they are your best effort. They will not be a rough draft unless otherwise stated. That means that finishing touches like checking layout, spelling, and grammar should all be applied. This point is also one where you can add value and exceed expectations. The trick is to add value without piling on deliverables. You may be able to add a few items, but the better approach is to increase the quality of the required items. In short, avoid bells and whistles. Add value by focusing on the requirements and delivering more related to them. This value can be quality, speed, maintainability, scalability, usability, or other improvements on a deliverable. Learn more in the book written for Develpreneurs at any stage in their progress: https://www.amazon.com/Source-Code-Happiness-Finding-Success-ebook/dp/B07MKZBF6R

No matter how good you are at your job, sooner or later communicating status will be required. A helpful hint is to avoid waiting until this becomes a requirement. Instead, get in the habit of regularly reporting your progress and status to your boss. Since this is a regular task, you should find the proper balance between keeping it short and providing enough detail. A Weekly Status Template First and foremost, try to keep your status report to a single page. The commonly accepted parts of this communication are, list what you did, list what you plan to do, list any issues or questions. Your weekly report should be able to capture these items in less than ten bullet points for each. You can then provide some notes or further details at the bottom of the page. When you keep it short like this then a page should be plenty. Your goal is to communicate a summary of what you are doing. If deep detail is needed then provide that in another document or meeting. I like to put the issues at the top so they are harder to miss. You might also want to include the hours worked on each item and a summary of billable hours for the week. This approach is not often needed for an employee. However, it is an excellent way to avoid billing surprises with the client. Communicating Progress Progress is a different issue from status. The goal of this communication is to provide a snapshot of where you are in a project. The status report may provide this information but not in the best format. Progress is something you want to provide in a sentence or two. Think about the CEO asking your boss how a project is going. The progress communication should be a quick, but accurate answer. Thus, you should be able to update your boss with this regularly without taking much time. Generally speaking, progress is often going to focus on whether it is on schedule and any big risks or wins. For example, our project is a few days behind schedule due to some snags hit with the vendor but we have had a demo with the sales department and they love it. Learn more in the book written for Develpreneurs at any stage in their progress: https://www.amazon.com/Source-Code-Happiness-Finding-Success-ebook/dp/B07MKZBF6R

A software consultant brings intellectual tools with them as well as applications. This capital comes in the form of experience and also the more concrete source code. That includes anything you take advantage of in your personal code repository. Although we typically are not fans of legal issues, we do need to spend the time reviewing contracts and ownership rights before we jump into that project or use our library. Using Your Code Repository There are two issues to understand when using your code. One is whether using that will contractually cause you to give up ownership. The other is whether a client allows you to use outside code in their project. You may think that the code you use that was previously written does not count as an external source. However, some situations will cause it to be viewed that way. In a similar vein, make sure you are legally allowed to re-use code written for a client. Your personal code repository should not contain any code that you do not have complete rights to use. The last thing you need is a legal battle among your customers. Who Owns The Work? The consulting contract should be clear on who owns the code you write for that customer. This agreement may also include license rights and related usage. The legal implications of this contract are such that you should have an attorney do a review before you sign. It is even better to have a boilerplate contract put together. Then get it reviewed by an attorney so you can be comfortable with the legalities of your employment. Failure to take these steps can bring you a pile of headaches. As always, better safe than sorry. Learn more in the book written for Develpreneurs at any stage in their progress: https://www.amazon.com/Source-Code-Happiness-Finding-Success-ebook/dp/B07MKZBF6R

One of the common aspects of consulting that is missed is clarity about developer tools and licenses. In particular, this obstacle is natural to overlook when you are used to being an employee. The challenge is not just being able to access the tools; you also have to navigate what can be used for your customers. Even more, there are applications you can use for your projects, but they are not licensed for your customers. Get Legal Developer Tools and Licenses Step one is to make sure you are adequately covered. Every tool you use (i.e., install on your machines) should be appropriately licensed. If you do not, then you might find yourself on the wrong side of a software audit. This situation is not only costly immediately in the form of fees; it also can cause a negative view of your company moving forward. The worst case is where you get a customer fined for your licensing mistake. Be safe out there. Similarly, make sure the tools you are licensed to use are also going to work for your customer. There are plenty of developer licenses that are fine right until you move into production. If your customer is required to purchase a license to launch their solution, then they need to know that sooner rather than later. They may tell you to find another solution or change the scope of the project to make it economically viable for them. The worst of these can be an application created with a user-based license and a large number of users. The costs can skyrocket, and margins can go to zero or worse. When in doubt, consult a lawyer. Synchronize Outside of the legal issues for tools, there is also a version aspect to review. There are cases where using a language or framework that is a different version from your customer will be fine. However, there are also many cases where that can be a critical problem. The work required to fix or merge your code in a different version can add up to more than what was required to code your changes. When in doubt, try to match everything used in a project including compilers, databases, IDEs, and any other tool that is a core part of the development. Learn more in the book written for Develpreneurs at any stage in their progress: https://www.amazon.com/Source-Code-Happiness-Finding-Success-ebook/dp/B07MKZBF6R

The completion of a project is not necessarily the end of a customer relationship. To the contrary, consulting project enhancements are a common way to keep that relationship alive. When that fails, a follow-up project also has a higher likelihood of being won than a new one. Take advantage of these options to keep your business thriving. Consulting Project Enhancements The first path to review is pitching enhancements. These are almost a slam dunk if you take good notes during the project creation process. There will be items scoped out of the project early in the requirements gathering through to the last minute. Even as late as deployment due to resource constraints. Every one of these is an opportunity for an enhancement release that includes it. There will also be ideas and features that come up during discussions with the customer. Some of these will be added as change requests, but some will be passed up for future enhancements. Once again, each of those is a candidate on your list of consulting project enhancements. Stay in Touch Follow-up calls are another great tool for keeping a client current. I recommend you start with one a few weeks after the deployment. This timing will allow for unforeseen issues to pop up as well as feedback from the final users. I have seen this sort of follow-up approach lengthen the life of a customer to many times the original agreement. If all is well, another follow-up a few months later or on a calendar basis. The beginning of the year tends to be safe. However, it is best to touch base with customers around the start of their budget process. This time frame is best suited for getting added on to a budget and getting signed up for a large project instead of a quick fix. Learn more in the book written for Develpreneurs at any stage in their progress: https://www.amazon.com/Source-Code-Happiness-Finding-Success-ebook/dp/B07MKZBF6R

Once you find a prospect your next step is turning them into a customer. In the IT world (as well as most other lines of business) this is done through a proposal. Therefore, writing proposals is a significant facet of growing a business. There is no black magic involved in this process; we just need some common sense. A Process for Writing Proposals Our focus on every project should be solving a problem or a group of them. Thus, the first step in our process for writing proposals is to fully define the problem or problems at hand. We can go off and try to figure it out on our own, but the customer is the best source for this information. Work with your customer to learn their pain points, and then repeat those back in your own words. When you take this approach, it helps them think more about the problem and dig deeper into specifics. Once you have the problems defined deep enough, share your understanding using your words. Do not parrot back the problem description. The goal is to ensure you (and the customer) understand the problem and how to communicate the details. Stay Focused Treat the problem definition as your foundation or cornerstone. As you create a solution, every facet of the solution should point back to that problem definition. This approach will help you avoid drift and useless bells and whistles. Keep your focus tight during the proposal phase. Those bells and whistles can always be reviewed with the customer after you have won the project. Do not take this approach as a form of bait and switch. Instead, you are proposing a sort of minimally viable product, and then they can add on later. That will allow them to be very aware of the cost of those additional features. Polishing Touches Once you have your content prepared, it is time to write the proposal. It is helpful to start by introducing yourself. Provides some reasons why you are a good fit for this project. After that light sales content move into the problem definition. It should be clear to any reader what the goal of the project is. The next step is to provide a summary of the proposed solution. Do not go deep into details. Leave this as a summary of the approach you will take. This proposal is not a design document. Wrap up with timing and costs. If you are going to produce a more detail proposal after the design phase, then mention that. A project is more likely to be successful if expectations have been adequately set from the start. Learn more in the book written for Develpreneurs at any stage in their progress: https://www.amazon.com/Source-Code-Happiness-Finding-Success-ebook/dp/B07MKZBF6R

The challenge of finding consulting projects is not one you should overlook. However, the first is the hardest. Once you have a couple of projects under your belt, you will find it easier to win additional work. We will cover the ways to grow existing business in another episode. For now, let's look at some ways to find prospects that are the easiest to convert into customers. Finding Consulting Projects on the Internet This problem is so common that a large number of sites have been created to solve it. That is not going to make your task a slam dunk. Although there are countless project sites out there, they are not all created equal. Start with the options that have a strong history and a substantial number of users. They may cost a little more, but the reliability is worth it. I have used Guru and Upwork (formerly ELance) for well over a decade and found some excellent clients. It has not been easy as I have responded to over one thousand requests over the years. Some of those were short, but over half were at least a page or two of proposal content. These sites are an excellent way to find small and medium-sized projects. Therefore, you should try them out and get comfortable with them as soon as possible. You may be able to stay busy without them. On the other hand, we all hit dry spells where these sites can help you survive them. Go With Who You Know The best way to find business is to go with people who know and trust you. That leads us to past employers and even co-workers. When you are looking for work, it is easiest to start by reaching out to places you have worked and the people you worked with. They know you, know how you work, and you will have a level of comfort with them as well. This is the perfect recipe for a successful project. That existing trust goes a long way in navigating the obstacles we often come across in IT work. Do not overlook your current employer. Sometimes there are projects that are available for a side hustle in your current job or with other departments. There may be some legal or employment restrictions related to these potential customers. Thus, you should take a good look at the political climate and your employment contracts before going down this road. Learn more in the book written for Develpreneurs at any stage in their progress: https://www.amazon.com/Source-Code-Happiness-Finding-Success-ebook/dp/B07MKZBF6R

One of the critical choices in accepting a project is whether you will bill based on a fixed or hourly basis. The bottom line is that one approach places more risk on you as a provider. The other puts it on the customer. At least, that is the typical thought. However, you can adjust a fixed bid or how the hourly rate is paid to shift risk around. Fixed or Hourly as a Project Approach I think that this is a decision that should be considered far more from the basis of how the project will go as opposed to finances. A fixed bid will make it far more likely that a customer will want to squeeze all they can into the project. On the other hand, the provider will try to keep it as thin as possible. That does not mean both parties are greedy or unfair. They are just going to focus on more or fewer features depending on where they sit. Even worse, a fixed bid can lead to a large number of hours spent on nailing down change requests and what should be included as part of the original definition. That is overhead that does not serve anyone. It may be me, but I find less haggling is a path to less stress. Finding Fairness There is not one approach that will be more intrinsically fair as pricing goes. The key to that always comes down to what is billed and what is not. There are arguments around pricing for bug fixes. However, you cannot be fair in that discussion without accepting that they do occur. That leaves it up to the provider to bill for hours worked and include bug fixes or not. If they do not bill for bug fixes, then the standard rate will need to go up. They are effectively being paid for their time. Thus, legitimate uses of time (including testing and bug fixing) need to be addressed. It may sound good to have an agreement where bug fixes or support will be free but that time will likely be covered in a higher general rate. Rather than try to solve fairness and budget concerns through fixed or hourly pricing, it is better to focus on requirements and estimates. A project that is well designed and defined will be easier to estimate in terms of hours worked, time elapsed, and total cost. At the end of the day, that is the goal of everyone involved. Learn more in the book written for Develpreneurs at any stage in their progress: https://www.amazon.com/Source-Code-Happiness-Finding-Success-ebook/dp/B07MKZBF6R

Whether you are running a side hustle or a full-blown business, at some point you will need to create consulting invoices. Well, unless you do not care about being paid for your work. This is a process that is often overlooked. However, the way you invoice can help you get paid on time, impress a client, and even market your services to expand the business. Consulting Invoices Are Not Redundant I have come across some consultants that feel like an invoice is redundant. Whether they sent a status with time worked or had a consulting agreement, they seem to think nothing else is required. They may send a bill, but decide that the extra work of an invoice is not needed to get paid. This is possible in some cases but still misses the point. Every interaction with a client is a chance to impress them positively or negatively. That includes communications with the accounting or billing department. You are letting an opportunity slip by if you do not spend the time on a professional looking invoice. Pacing and Surprises It is also tempting to send an invoice only when you need the money or work is complete. Although that may be the agreement, it is not a recommended approach. A few smaller invoices will be more likely to get paid (at least partially) than a single, large invoice. They will often get paid faster as well. Just as you should be providing regular progress on a project to the customer, they should make the scheduled payments for your fees. That holds for a fixed-bid project as well. Set a time frame with your customer that makes sense (weekly, monthly, quarterly, etc.) and invoice them on that schedule. You can bill a percentage of a fixed bid project or hours worked for a given time period. I know that accounting can be an annoying overhead. On the other hand, regular billing can help your receivables stay within a reasonable range and help you avoid the headaches around getting paid for work done long ago. You put in the work and should be producing quality deliverables. With that in mind, there is no reason for a customer to avoid paying invoices on the schedule you agree upon. When that becomes a problem, the conversations and project quality can be less than you desire. As usual, the more you can get ahead of these things, the easier it is to avoid mistakes and arguments. Learn more in the book written for Develpreneurs at any stage in their progress: https://www.amazon.com/Source-Code-Happiness-Finding-Success-ebook/dp/B07MKZBF6R