Project Warning Signs
A vast number of software development projects happen daily around the globe; Slice Networks can only be responsible for properly executing a handful of them. However, many businesses sense instinctively their current projects are not going well. To help identify if your project is on track, let's discuss the most common warning signs. If they sound familiar, begin to manage your development partner very carefully, or contact us to consider a switch.
1. You don't own the source code, either contractually or physically.
Source code is the set of files dictating to the computer how your software runs. These instructions are used to build the actual program. You need two types of ownership: to contractually own the source code and to have physical possession of the latest version. read more [+]
You share your idea with an outside company, and pay them to develop it for you. Your contract must explicitly state that you have 100% ownership of the code, and that your vendor sacrifices all interest. If it does not, it is equivalent to paying somebody to design a product from scratch, but you don't get the blueprints, specifications, or formulae! Congratulations, you have just paid somebody else to develop and profit from your concept.
Just as important is physical possession of the code. Always keep a recent working copy of the source code files, completely separate from your development team. If anything goes wrong with the vendor or your relationship with them, now you have leverage. If your vendor has the only copy, they possess your entire investment in those files; any negotiations may now become very difficult. Only if you have the latest copy can you take it to another reputable company and continue your valuable work.
At Slice Networks, we surrender all rights to the source code in the contract, providing you 100% ownership. Additionally, we regularly checkin copies of the physical source code to you, ensuring that should something happen to us, your important work will continue. It's simply the right way to do business.
2. Poor or no specifications.
Specifications detail the software architecture so that the client and developers are referencing the same blueprints. Lacking good specifications, people make uninformed mid-project decisions, often with unforeseen consequences. read more [+]
The cornerstone of good development, solid specifications take time, talent, and effort to develop. They lay out critical development details: screen shots with the user interface, functionality instructions, architecture notes, and use cases. Every $1 spent on a specification deciding a detail in advance eliminates $10 worth of changes during coding and $100 worth of changes on a production system! We have seen specifications as poor as all verbal supported only by handwritten notes, sketchy outlines, or brief email summaries. These shams are insufficient to capture the subtleties of new software, as the devil is in the details. Your software deserves a well written specification, so that you can attach accurate cost, timelines, and architecture to it.
Beware of vendors who don't want your key managers to participate in specification reviews. Only your personnel, with intimate knowledge of your business' inner workings, can state whether the proposed software will work as designed. If they have not reviewed the spec and signed off on the details, the software being built is unlikely to meet their needs. This leads to disappointment, slipped schedules, substantial code changes, and a general "wondering what went wrong" during deployment.
At Slice Networks, we write solid specifications for each project, and hold both client and internal team reviews of every one. During those reviews, our developers must buy-in to delivering the commitments made by each specification. This means our software meets your goals every time we complete a project.
3. Your programmers frequently and inexplicably stall on simple issues.
Prospects share with us that their developers "said this feature was simple, and it should have been delivered six months ago". Well that frequently indicates one of two issues: lack of a proper specification, or an incompetent or poorly led development team. read more [+]
In practice, unforeseeable engineering issues do arise during software development. After all, good development will always be a mix of art and science; separating the simple from the complex takes experience. Your vendor should be able to clearly explain why a particular issue is complex and offer viable solutions, including time, budget, or feature changes. However, this shouldn't be the consistent theme of your project. Simple issues constantly being represented as complex is a telltale sign the development team is disorganized, missing a well-written (or any) specification, lacking guidance by experienced senior staff, or simply incompetent. Too many supposedly "complex" issues means you will miss both your deadline and budget.
At Slice Networks, our projects usually contain tricky parts. Frequently, that's why we took the project in the first place. The straightforward parts you will rarely hear about; we simply execute them with excellence. The tricky parts get your attention during implementation; we need your input, as the complexity usually reflects custom business logic. Practicing this distinction means your software gets done on schedule, budget, and specification.
4. Constant team changes and turnover
Prospects often tell us that their development team has turned over completely twice during the last year. Occasional staff changes are expected, but any vendor constantly switching teams isn't pursuing your project's best interests. read more [+]
Even with perfect written documentation, developer's minds are still a key source of knowledge. Nobody will ever know the code better than the programmers who wrote it. Every time your vendor moves their team to another assignment, you lose all their accumulated experience. The token two-week transition period is rarely sufficient to transfer months or years worth of knowledge. The more often new developers have to climb a project's learning curve, the farther behind the schedule slips.
On a larger note, constant team changes hint at the state of your vendor. They may not have enough resources to support their current workload, and are moving teams around to meet the most urgent need. Frequently they're trying to grow their business faster than they should, or are struggling to keep current customers. Commonly they're moving around their "A-team" to attract new clients. Any of these practices means they"re not focused on your project.
Slice Networks tackles this problem from two directions. We engage on interesting projects to keep our engineers in good spirits, so we have lower turnover. We repeatedly work with the same employees and subcontractors, consistently earning their loyalty. Also, we grow our business at reasonable rates so we don't overload our senior talent, ensuring they are dedicated to the project we committed them to.
5. Low participation from vendor's senior staff
Senior staff with a solid mix of business acumen and technical experience are among the most valuable members of your project. The project managers, software architects, and product managers must regularly participate throughout both the business discussions and software development, or your project will go off track. read more [+]
Senior staff make or break a development project. They create the software requirements for engineering; they MUST spend sufficient time becoming intimately familiar with your business, values, key employees and critical processes. Without this understanding, they cannot specify software that will suit your needs. We all know how critical good specifications are.
Disengaged or underparticipating senior staff create a more subtle problem. When insufficient understanding leads to improper specifications, the software engineers are left to make key business decisions as they code. This is dangerous; engineers rarely code from the business perspective, so the end results will not match the business need. Good senior staff are making daily decisions throughout development, in conjunction with the clients and engineers.
Slice Networks solves this problem simply. We don't accept more work than we have available senior staff. We consistently choose to produce less volume but higher quality work, rather than stretch our talent too thin. See? Problem solved.
6. Poor project management
Good project management is essential; it keeps the moving parts of projects running smoothly. Yet it is often given the back seat in software development projects. read more [+]
Real-world software projects are far from perfect: they face a range of events such as requirement changes, serious bugs, milestones achieved, and features released. Since these are part of every real-world project, they should be regularly discussed and certainly not ignored, so there are no surprises. This regular client communication is critical to minimizing their impact on scope, schedule, and budget.
Software development projects usually require a great deal of internal preparation by the client. All too often, there is little discussion of this critical work: specification reviews, content production, and creating business logic documents take a great deal of time and effort. Helping both the client and engineers manage this workload and progress on schedule is a critical part of a project manager's role.
Finally, long term software projects should always be worked on in multiple phases simultaneously. The team should be working on 3 phases: bug fixing and performance enhancements in the current code base, programming the latest features, and writing specifications to plan future feature release.
Slice Networks acknowledges the reality that all software projects change from beginning to end as the engineering problem is fully explored during coding. We choose to communicate frequently about these issues, which results in happier clients and more accurately met scopes, schedules, and budgets.
7. No documentation
Good documentation of each project is mandatory. In addition to specification documents (business requirements, functional specifications, etc.), the code itself needs to be well-documented. That way it is maintainable over its lifetime, saving you time and money in later project stages. read more [+]
While good documentation doesn't directly affect daily use of your software, it certainly affects its overall maintainability, and therefore cost. Good programmers write notes as they code, describing the rationale for writing that section. No matter how talented, no two developers think alike, so "why I programmed it this way" notes are important. A competent successor can read the notes, know their thinking when they wrote the code, and pickup where they left off. People transfer to different projects during their careers, and you want to maintain as much of their knowledge as possible. The more unique, complex, or interesting the software is, the more likely the next programmer will need to know what their predecessor was thinking.
At Slice Networks, our developers document their code, especially the tricky parts. We provide you every specification we write, during each phase of every project. This means when we upgrade your software in the future, everybody can refer to the original design documents and implementation notes, and make smart decisions about how to best improve your software.