This is the third in a series of posts covering Custom Projects. See the list of links at the bottom of this post.
A company that performs custom development needs to have a coherent Product Management scheme. Also needed are a set of standards for managing the various kinds of projects undertaken. How do custom projects start, execute, and stop?
It is well worth the effort to create a document to describe how projects are run at your company. In fact, if you are performing Custom Development it is essential to have such a description. You should include the 5 major cases where projects come from: RFP proposals, requests for new features through customer support, bug reports that turn into new feature requests, custom work brought in by the sales team, and roadmap development activities on the core product. There are three key matters to get documented:
- Define a well-known location for a repository for all such project requests. Consider using the Issue Repository for this purpose.
- The repository should hold all relevant information for planning the project: description, technical scope summary, preliminary effort estimates and delivery dates for the major components, who owns the responsibility for taking the project to the next step, and some indication of the status or state of the project. Some care should be taken to define these project states in a complete and generic way. Stipulating the conditions under which the project state changes is important.
- Describe the flow of activities, similar to the (over) simplified picture below about the stages of engagement with the customer and the key artifacts to be produced a teach stage.
A very important issue is to make an unambiguous statement about who decides whether to undertake a project with what priority. Product management or the equivalent Larry-Page-styled executive needs to be identified. The role is crucial to success: you need someone with the big picture of product-market fit and product cadence, which is directly connected to the strategy of the company. Most relevant here is to define a single point, where decisions are made on whether to undertake a given Custom Project and whether to (also) include into the product baseline the features to be developed. This requires a lot of commerce between the engineering and product management teams. But the ultimate decision must be Product Management.
Even though it is somewhat artificial, making sure that projects are force-ranked (only one project per priority level) during the planning stage prevents debilitating ambiguity later on. It is also important to note that the order in which projects are completed is not necessarily the same as the priority. It really depends on size and opportunity: small projects of lower priority may be completed before complex projects of higher priority. Obviously, discretion needs to be used to limit the delays to high-priority projects, where there are resource conflicts.
It is important to write a description about how business will be conducted with the customer under a Custom Project. In fact, you will need to create some Services Agreement prior to performing custom development. This agreement will typically say something about the Engagement model or models to be used with this customer. Further, the Services Agreement will stipulate payment terms, intellectual property, basis for pricing projects, project governance (key people on both teams, project review meetings, etc.), and a description about the stages of projects and artifacts to be agreed at each stage (see a simplified version of this process in the diagram above.) In case that you may want to run a number projects with the same customer, it is useful to create a separate Agreement, so you don't have to worry about the legal terms for each project. This agreement is typically called a Master Services Agreement or MSA.
When you get all of these details under control at the beginning, you will find that it is much easier to deliver individual projects without a lot of churning, confusion, and uncertainty. The cost of this up-front work is returned many-fold in productivity, and the satisfaction of just getting things done successfully.
Comments