How We Work
by Brett Porter, Chief Engineer
Many of the clients who we work with either have little experience with software development, or have experience with development, but not using an external custom development shop like Art & Logic. As a result, there can sometimes be misconceptions and confusion about what it's like to work with us on a project.
Estimates and Proposals
The first step in any project that we do will be to work with the client to determine the list of features that will be needed for the project to be successful. We can build this list in a number of ways, whether from an existing specification document, using emails and phone calls, sketches, or looking at existing versions of similar projects. Once we know what it is that needs to be built, we'll have one or more developers break those features down into a number of individual pieces that are as small as possible, and then estimate the effort that would be required to implement each of those pieces.
One problem that is typically seen on software development projects is that developers are often overly-optimistic about the amount of time needed to perform a task, failing to account for unanticipated difficulties or prerequisites that aren't readily apparent during the estimation process. One way that we compensate for this is by using an estimation technique called 'Pessimistic PERT'. For each item called out in the estimate, the estimator assigns three values; the best-case amount of time to complete the task, the most likely amount of time, and a worst-case amount of time. We apply a formula to those three values and calculate an 'expected case' value for each item. The sum of those tasks estimates, plus additional factors for other required activities like project management and testing the project add together to create a estimate for the project.
Staffing up the Project
Every project that we work on has people filling the following roles:
Account Manager: The Account Manager for your project is usually the same person who was your primary contact during the estimate and proposal process. He will be your point of contact for all matters relating to the business aspects of the project, and will remain in contact over the life of the project to ensure that everything is running smoothly.
Project Manager: The Project Manager is responsible for planning and managing the design and execution of the project. On small projects, the Project Manager may also be the entire development team, or he may be working as a member of a larger development team within Art & Logic. We find that projects are most successful when all technical discussions about the project are handled directly between the Art & Logic Project Manager and a single technical counterpart within the client organization. By requiring that all these discussions go through this channel helps ensure that there are no surprises from contradicting messages being sent between various people in the two companies.
Development Team: When assigning developers to the team for a project, we take into account many factors, including the client's schedule needs, desired monthly burn rate, how well-defined the project is, and what the ideal team size for the project would be. For example, a project that starts out with many unknowns will most likely kick off with just a project Manager and a designer, who will work together to develop one or more prototypes to help the client explore their real requirements. Once the required features for the project become more stable, we would only then assign additional developers to the team. We're able to react quickly with different team sizes as conditions warrant. A common misconception among clients is that be staffing their project with a larger team, the project will be completed more quickly; in software development, this belief is known as "The Mythical Man-Month" (see http://en.wikipedia.org/wiki/Mythical_man_month). We've found that small teams of highly skilled developers can finish projects more quickly and adaptively than larger teams could. All of our developers and project managers are trained to follow a common set of development practices, including our programming Style Guide (see http://www.artlogic.com/careers/styleguide.html) that make it easy to bring new team members in to work on projects already in progress.
Communication within the team and between Art & Logic and our clients is mostly done using a collaboration server called "FirstClass". This provides for each client a secure and private conference that's only visible to authorized client contacts and our developers. This conference is used to contain the complete history of all written communication relating to the project. It's much easier for everyone involved to be sure that details aren't being forgotten about when there's a single place to hold all discussion of those details.
Project Lifecycle
Once the project is in progress, we break the project down into a number of iterations, generally between 2 and 4 weeks in length. Each iteration is run as if it were its own little project, with these stages happening every time:
Preparation: The Project Manager and development team meet to go through the list of features and tasks that aren't finished yet, and re-estimate the work required to complete them. Typically, as we get deeper into a project, the requirements change at least subtly in ways that have impact on the number of hours required for the project. Just as often, as clients start seeing development releases of their project, new requirements are added to the project. By performing this re-estimation at the beginning of each iteration cycle, we have an opportunity to resynchronize everyone's understanding of where the project is, where it's headed, and our estimate of how much the remainder of the project will cost after factoring in new or changed requirements, our improved understanding of the known requirements, and our performance with regard to estimates so far on the project.
The team selects tasks from the list of undone work to be performed in the next iteration. This selection is done based on criteria like reducing any known technical risks (for example, if the project requires that we interoperate with new hardware or protocols, or uses externally provided programming interfaces that are still in development), creating any modules or subsystems that would block future work, or developing prototypes for client feedback as early in the project as is appropriate. For projects that are deployed to end users, client feedback will guide the team to work on features that will provide the most immediate value.
Execution: The bulk of each iteration is taken up with an execution phase, where the Project Manager assigns tasks to the development team, and the team does whatever work is needed to complete the tasks.
Transition: The end of each iteration includes any work that's required to verify that the new work done in this iteration was completed correctly (by testing) and cleanly (by performing peer code reviews). If the planned output at the end of the iteration was a release to the client, the release is prepared and delivered, along with release notes. In an ongoing project, this phase of the iteration will usually overlap with the Prep phase of the subsequent iteration, as the team works together with the client to plan the work that will be done next.
Long Term Relationship
In reality, most software projects don't really end; as users work with the first release of a software product they quickly begin identifying improvements. We take pride in the number of our clients who continue to work with use over many years and versions of their products to provide these enhancements.
Many of the clients who we work with either have little experience with software development, or have experience with development, but not using an external custom development shop like Art & Logic. As a result, there can sometimes be misconceptions and confusion about what it's like to work with us on a project.
Estimates and Proposals
The first step in any project that we do will be to work with the client to determine the list of features that will be needed for the project to be successful. We can build this list in a number of ways, whether from an existing specification document, using emails and phone calls, sketches, or looking at existing versions of similar projects. Once we know what it is that needs to be built, we'll have one or more developers break those features down into a number of individual pieces that are as small as possible, and then estimate the effort that would be required to implement each of those pieces.
One problem that is typically seen on software development projects is that developers are often overly-optimistic about the amount of time needed to perform a task, failing to account for unanticipated difficulties or prerequisites that aren't readily apparent during the estimation process. One way that we compensate for this is by using an estimation technique called 'Pessimistic PERT'. For each item called out in the estimate, the estimator assigns three values; the best-case amount of time to complete the task, the most likely amount of time, and a worst-case amount of time. We apply a formula to those three values and calculate an 'expected case' value for each item. The sum of those tasks estimates, plus additional factors for other required activities like project management and testing the project add together to create a estimate for the project.
Staffing up the Project
Every project that we work on has people filling the following roles:
Account Manager: The Account Manager for your project is usually the same person who was your primary contact during the estimate and proposal process. He will be your point of contact for all matters relating to the business aspects of the project, and will remain in contact over the life of the project to ensure that everything is running smoothly.
Project Manager: The Project Manager is responsible for planning and managing the design and execution of the project. On small projects, the Project Manager may also be the entire development team, or he may be working as a member of a larger development team within Art & Logic. We find that projects are most successful when all technical discussions about the project are handled directly between the Art & Logic Project Manager and a single technical counterpart within the client organization. By requiring that all these discussions go through this channel helps ensure that there are no surprises from contradicting messages being sent between various people in the two companies.
Development Team: When assigning developers to the team for a project, we take into account many factors, including the client's schedule needs, desired monthly burn rate, how well-defined the project is, and what the ideal team size for the project would be. For example, a project that starts out with many unknowns will most likely kick off with just a project Manager and a designer, who will work together to develop one or more prototypes to help the client explore their real requirements. Once the required features for the project become more stable, we would only then assign additional developers to the team. We're able to react quickly with different team sizes as conditions warrant. A common misconception among clients is that be staffing their project with a larger team, the project will be completed more quickly; in software development, this belief is known as "The Mythical Man-Month" (see http://en.wikipedia.org/wiki/Mythical_man_month). We've found that small teams of highly skilled developers can finish projects more quickly and adaptively than larger teams could. All of our developers and project managers are trained to follow a common set of development practices, including our programming Style Guide (see http://www.artlogic.com/careers/styleguide.html) that make it easy to bring new team members in to work on projects already in progress.
Communication within the team and between Art & Logic and our clients is mostly done using a collaboration server called "FirstClass". This provides for each client a secure and private conference that's only visible to authorized client contacts and our developers. This conference is used to contain the complete history of all written communication relating to the project. It's much easier for everyone involved to be sure that details aren't being forgotten about when there's a single place to hold all discussion of those details.
Project Lifecycle
Once the project is in progress, we break the project down into a number of iterations, generally between 2 and 4 weeks in length. Each iteration is run as if it were its own little project, with these stages happening every time:
Preparation: The Project Manager and development team meet to go through the list of features and tasks that aren't finished yet, and re-estimate the work required to complete them. Typically, as we get deeper into a project, the requirements change at least subtly in ways that have impact on the number of hours required for the project. Just as often, as clients start seeing development releases of their project, new requirements are added to the project. By performing this re-estimation at the beginning of each iteration cycle, we have an opportunity to resynchronize everyone's understanding of where the project is, where it's headed, and our estimate of how much the remainder of the project will cost after factoring in new or changed requirements, our improved understanding of the known requirements, and our performance with regard to estimates so far on the project.
The team selects tasks from the list of undone work to be performed in the next iteration. This selection is done based on criteria like reducing any known technical risks (for example, if the project requires that we interoperate with new hardware or protocols, or uses externally provided programming interfaces that are still in development), creating any modules or subsystems that would block future work, or developing prototypes for client feedback as early in the project as is appropriate. For projects that are deployed to end users, client feedback will guide the team to work on features that will provide the most immediate value.
Execution: The bulk of each iteration is taken up with an execution phase, where the Project Manager assigns tasks to the development team, and the team does whatever work is needed to complete the tasks.
Transition: The end of each iteration includes any work that's required to verify that the new work done in this iteration was completed correctly (by testing) and cleanly (by performing peer code reviews). If the planned output at the end of the iteration was a release to the client, the release is prepared and delivered, along with release notes. In an ongoing project, this phase of the iteration will usually overlap with the Prep phase of the subsequent iteration, as the team works together with the client to plan the work that will be done next.
Long Term Relationship
In reality, most software projects don't really end; as users work with the first release of a software product they quickly begin identifying improvements. We take pride in the number of our clients who continue to work with use over many years and versions of their products to provide these enhancements.
posted by James at
1:21 PM
<< Home