Develpreneur: Become a Better Developer and Entrepreneur

An excellent measure of long-term success is how much your customers like you.  Thus, building relationships are a critical part of your job.  You may have the skills to be able to stay busy without the "personal touch."  However, life will be simpler when you create some advocates along the way. Building Relationships Organically Your primary focus should be solving problems.  When you do this, it is hard for people to not be positively biased towards you.  We have a hard time disliking those that remove our pain points.  On the other hand, a doctor with a bad bedside manner may end up being an alternative decision rather than a primary physician.  The good news is that your normal schedule will include a lot of opportunities for building relationships. Meetings are a perfect example.  That "dead" time at the beginning of meetings, while you are waiting for everyone to join, is great for small talk.  You can ask about recent events or even play it safe and talk about industry news.  When you show yourself to be approachable it will make it easy for others to be affable.  These sort of little connections can help you build a relationship over time. Get To Know Your Customer The process of gathering requirements can be a way to learn how your customer ticks.  The design phase and related feedback will be even more so.  These tasks include a lot of discussion with your customers that is centered around their likes and desires.  This information is an excellent foundation for building bridges.  I am often surprised at the ways a design decision teaches me about the people around the table.  Simple things like color choices may lead to discussions of alma maters or favorite sports teams. Regular Contact Any marketing book or tutorial will bring up the idea of staying on the mind of a customer.  That is why a brand is so important.  You can build a brand and stay current with customers by sending them regular (useful) content.  For example, a monthly newsletter is a common way to "touch" customers and try to stay in front of people's minds. Relationships are critical to sales and growth.  Take advantage of "quality time" with your customers to build a rapport early and often. 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  

We have touched on the idea that there are explicit and implicit project deliverables in most cases.  These may be due to our customer simplifying a solution or general prerequisites and best practices.  Some common implicit project deliverables include documentation, test scripts, demonstrations and the like.  We need to take all of these into account for our estimates and risk calculation. A Complete List I have found that one of the most significant contributors to bad estimation in software is missing requirements.  We spend time on designing the explicit features and let the implicit ones fall through the cracks.  Then those missed items pop up during the project and add a little (or a lot of time) to the schedule.  These "oops" items add up and can be significant to the point of long hours or slipped dates. You may point out that experience should reduce or eliminate these missed items.  That is correct.  However, it is easy to forget about these items unless we follow a detailed process in planning out the project. Estimating Implicit Project Deliverables The other problem with these assumed requirements is estimating them.  They tend to be dependant upon the overall requirements and system complexity.  My favorite examples of these are testing, documentation and general project management or meetings.  Each of these items is part of almost every project.  However, they are easy to estimate incorrectly due to their reliance on the project as a whole to determine size and effort. Documentation is the easiest to evaluate.  We just need to be clear about the packaging for the end solution.  This should include answering the questions about the user, installation, administrator, technical and other guides.  Testing and general project management (status updates, creating tasks, assigning them, and tracking progress) are often underestimated.  The challenge with these is the cost per "cycle."  For example, when you have weekly meetings to plan, share and discuss progress then that overhead will increase as the project timeline grows.  Test cycles work in a similar fashion.  When we add a partial or beta release to a project then we need to include testing impact with that estimation. The explicit and implicit project deliverables are not hard to determine.  However, we need to be intentional about including all of them in our planning.  Sometimes it is best to slow down, take a deep breath, and review our plan to catch all of these critical items. 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  

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