Once the initial project plan is completed with tasks listed, it is time to estimate the time required for the implementation.
First, you should have the people who will performing the various tasks estimate the time required for those tasks. In most cases, because the majority of the tasks involve software development, it will be the programmers who will be making the quotes for the majority of those tasks.
In any case, the best estimate for each task comes from the person who will be performing that task. Clearly they will be best able to evaluate the amount of time required for that task.
But there is another benefit. If you get the estimate for the amount of time to complete the task from the person who will actually perform the task, then you get an implicit commitment from that person to perform the task in that amount of time. On the other hand, if someone else (such as the project manager) estimates the amount of time required for a particular task but that estimate turns out to be too low, the programmer won’t have the same level of commitment. In that case, after all, it is only someone else’s quotation.
In some, probably many cases, you won’t know at the time of the quote who will be performing a particular task. In that case I recommend having the functional manager quote the tasks. When you do that you are at least getting a commitment from the manager of the person who will have to perform the task. If you can’t get either one, then do the best you can. But build some contingency into the schedule.
I recommend that all task estimates should INITIALLY be made as though they had to be performed from scratch, even though in some cases you may be duplicating something that has already been done. Assuming that everything is done from scratch gives you the worst-case scenario. Note that it is still important to factor in risk and make other adjustments. I talk about those later.
Thursday, March 26, 2009
The Project Plan should be based on the SRS
Although it is reasonable to develop preliminary plans, the project plan to be used for estimating the cost of the project should be developed only after the Software Requirements Specification has been approved by the customer. Once the spec has been approved, tasks should be created in the project plan.
Each task in the project plan should have a reference back to a specific section of the SRS. If you do this, then it is easy to handle questions about each task as you quote the time required for the implementation.
So what is the best way to do that?
I’ve tried putting paragraph numbers from the SRS into the project plan as references. Unfortunately that only works until you first modify the SRS.
Instead I recommend giving each requirement in the SRS a unique name and then using those names in the project plan. For example, a section of the SRS may say “Aging Report” and the project plan will have a task titled “Aging Report”. It is easier to avoid changing the names of sections in the SRS than it is to avoid changing section numbers.
Ideally some software would allow the SRS and the project plan to be linked together. I haven’t seen any software yet that allows us to do that.
Each task in the project plan should have a reference back to a specific section of the SRS. If you do this, then it is easy to handle questions about each task as you quote the time required for the implementation.
So what is the best way to do that?
I’ve tried putting paragraph numbers from the SRS into the project plan as references. Unfortunately that only works until you first modify the SRS.
Instead I recommend giving each requirement in the SRS a unique name and then using those names in the project plan. For example, a section of the SRS may say “Aging Report” and the project plan will have a task titled “Aging Report”. It is easier to avoid changing the names of sections in the SRS than it is to avoid changing section numbers.
Ideally some software would allow the SRS and the project plan to be linked together. I haven’t seen any software yet that allows us to do that.
Using Customer Commitments in the Project Plan
One differentiator between standard and custom software development projects is that on custom projects, customers will have commitments that they have to meet in order to achieve the schedule.
On standard software developments, customers are contacted prior to beginning the development in order to get feedback on the features in the software which are important to those customers. But once the development goals are defined in the specification, very little customer involvement will take place, except for the possibility of having the customer do some pre-release “beta” testing of the program.
On custom software development projects, the customer will have more significant involvement in completion of the project. First and foremost, the customer needs to agree on the definition of the project’s features and scope as described in the SRS. But in addition to that, the customer may need to provide the actual servers and/or workstations that will be used in the implementation. Occasionally other specialized equipment must be supplied by the customer. Often, for testing purposes, the customer needs to provide test data
So one key aspect of managing custom software design projects is managing the customer in order to help them recognize and meet these various commitments. The project plan is an important tool to use for this purpose.
The customer should also be included in the project plan as one of the resources. Anywhere within the project plan that you need something from the customer (approval of a specification, delivery of some test data, etc.) make sure that the task is listed and assigned to the customer. In all cases, the customer should be made aware of the commitments that have been assigned to them when the project plan is first approved and whenever it is updated.
For all such customer commitments, you should also add a preliminary task, assigned to the project manager, to remind the customer of upcoming commitments that have been assigned to them. When the project manager reminds the customer, the reminder should be as a gentle reminder, in writing (most likely an email) and the reminder should lay out for the customer the schedule implications if the commitment is not met or if it is delayed.
And, of course, these tasks / commitments should be reviewed whenever there is a project review meeting with the customer. The project manger’s own managers should be aware of all such customer commitments, especially when the customer does not meet any such requirement.
So why do all of this? Is it simply to cover your ass (CYA)?
Admittedly that is a part of it. But much more importantly you must understand the customer’s perspective of the project.
The customer is very interested in meeting the schedule. In fact, as I’ve mentioned already, I believe that in most cases the schedule is the most important single aspect of the project for the customer - especially if the solution is based on a fixed-cost quote. But the customer is depending on the vendor to provide the solution within that schedule. It is easy for them to overlook those things that they need to provide.
I’ve never seen a customer who complained about being reminded of their own commitments. But this is one of the reasons that the vendor should have a good relationship with the customer.
On standard software developments, customers are contacted prior to beginning the development in order to get feedback on the features in the software which are important to those customers. But once the development goals are defined in the specification, very little customer involvement will take place, except for the possibility of having the customer do some pre-release “beta” testing of the program.
On custom software development projects, the customer will have more significant involvement in completion of the project. First and foremost, the customer needs to agree on the definition of the project’s features and scope as described in the SRS. But in addition to that, the customer may need to provide the actual servers and/or workstations that will be used in the implementation. Occasionally other specialized equipment must be supplied by the customer. Often, for testing purposes, the customer needs to provide test data
So one key aspect of managing custom software design projects is managing the customer in order to help them recognize and meet these various commitments. The project plan is an important tool to use for this purpose.
The customer should also be included in the project plan as one of the resources. Anywhere within the project plan that you need something from the customer (approval of a specification, delivery of some test data, etc.) make sure that the task is listed and assigned to the customer. In all cases, the customer should be made aware of the commitments that have been assigned to them when the project plan is first approved and whenever it is updated.
For all such customer commitments, you should also add a preliminary task, assigned to the project manager, to remind the customer of upcoming commitments that have been assigned to them. When the project manager reminds the customer, the reminder should be as a gentle reminder, in writing (most likely an email) and the reminder should lay out for the customer the schedule implications if the commitment is not met or if it is delayed.
And, of course, these tasks / commitments should be reviewed whenever there is a project review meeting with the customer. The project manger’s own managers should be aware of all such customer commitments, especially when the customer does not meet any such requirement.
So why do all of this? Is it simply to cover your ass (CYA)?
Admittedly that is a part of it. But much more importantly you must understand the customer’s perspective of the project.
The customer is very interested in meeting the schedule. In fact, as I’ve mentioned already, I believe that in most cases the schedule is the most important single aspect of the project for the customer - especially if the solution is based on a fixed-cost quote. But the customer is depending on the vendor to provide the solution within that schedule. It is easy for them to overlook those things that they need to provide.
I’ve never seen a customer who complained about being reminded of their own commitments. But this is one of the reasons that the vendor should have a good relationship with the customer.
Saturday, March 21, 2009
Using the Project Plan for scheduling
If you are making a cost quote, all you really need are the total hours required to implement the solution. The project software program you use should be able to compile a total number of hours for you. But the schedule basically comes for free, or at least takes a minimum of effort. Moreover, including the schedule can have an impact on costs.
But the primary reason for developing a schedule is that the customer will inevitably ask for at least a ballpark quote of how soon the solution can be delivered when he is given the cost estimate. The scheduling part of the project plan will provide that.
It is often difficult to provide a specific schedule commitment when providing a cost estimate (saying, for example, that the solution will be delivered 24 weeks after receipt of the order). The fundamental problem is that it does not make sense to begin work before an order is received. If you don’t know exactly when the order will be received, you don’t know if it will compete with other orders. (While having many orders come in for custom software development is actually a good thing, it does create at least the potential for competition for key resources.) Once the order comes in, you should be able to commit to a specific schedule.
Certainly one factor is the size of the order. If the order is large, consisting of multiple person-years of work, it should be possible to plan for an amount of time to get the necessary resources together and then provide the customer with a schedule commitment at the time that a cost estimate is created.
On smaller project, it is my experience that multiple orders will come in simultaneously (or nearly simultaneously). I’m sure a part of that is due purely to Murphy’s Law, but another part of it involves the way that businesses purchase things like custom software projects. The process that they use is to get an estimate, work to justify it, add it to the company’s budget and then actually order it when the fiscal year begins. I received more orders for new custom software projects during the first month of the calendar year, and certainly during the first month of each quarter, than during the other parts of the year. This is because business fiscal years tend to align with calendar years, and they nearly all align with the beginning of calendar quarters.
Occasionally – especially when responding to an RFP – the customer will tell you when the order will be given to you (if they accept your bid). In that case it is reasonable to provide a commitment for a specific delivery date. Otherwise, I consider such commitments to be very dangerous.
In order to use the project plan for scheduling, you need to put in proper dependencies (e.g. task 2 depends on the completion of task 1). You should also make the schedule dependent on a single initial task (such as receiving the purchase order) which, if changed, will correctly change the entire schedule. It is easier to test “what if” sorts of scenarios when you do that..
But the primary reason for developing a schedule is that the customer will inevitably ask for at least a ballpark quote of how soon the solution can be delivered when he is given the cost estimate. The scheduling part of the project plan will provide that.
It is often difficult to provide a specific schedule commitment when providing a cost estimate (saying, for example, that the solution will be delivered 24 weeks after receipt of the order). The fundamental problem is that it does not make sense to begin work before an order is received. If you don’t know exactly when the order will be received, you don’t know if it will compete with other orders. (While having many orders come in for custom software development is actually a good thing, it does create at least the potential for competition for key resources.) Once the order comes in, you should be able to commit to a specific schedule.
Certainly one factor is the size of the order. If the order is large, consisting of multiple person-years of work, it should be possible to plan for an amount of time to get the necessary resources together and then provide the customer with a schedule commitment at the time that a cost estimate is created.
On smaller project, it is my experience that multiple orders will come in simultaneously (or nearly simultaneously). I’m sure a part of that is due purely to Murphy’s Law, but another part of it involves the way that businesses purchase things like custom software projects. The process that they use is to get an estimate, work to justify it, add it to the company’s budget and then actually order it when the fiscal year begins. I received more orders for new custom software projects during the first month of the calendar year, and certainly during the first month of each quarter, than during the other parts of the year. This is because business fiscal years tend to align with calendar years, and they nearly all align with the beginning of calendar quarters.
Occasionally – especially when responding to an RFP – the customer will tell you when the order will be given to you (if they accept your bid). In that case it is reasonable to provide a commitment for a specific delivery date. Otherwise, I consider such commitments to be very dangerous.
In order to use the project plan for scheduling, you need to put in proper dependencies (e.g. task 2 depends on the completion of task 1). You should also make the schedule dependent on a single initial task (such as receiving the purchase order) which, if changed, will correctly change the entire schedule. It is easier to test “what if” sorts of scenarios when you do that..
Quoting Custom Software Development Projects
Of course the necessary first step of any software project – custom or otherwise – is to define the requirements as described in the previous BLOG entry. Once that is done, a quotation for the work to be performed can be created.
To emphasize the point: if you don’t understand that you really, really need a good definition of the requirements, go back and read the entry titled “Defining Requirements” again.
The Project Plan
Once you have a good definition of the requirements, a detailed project plan should be developed for the purpose of creating the cost and schedule quotations for the custom software development project. I have had particular success using the Microsoft Project program for creating such quotes. No doubt other software packages that can also do the job. Regardless of the software package you use, it should be able to implement the elements listed below.
Project plans have many uses. One of those uses is to track the progress of the project as it is implemented. Particularly in projects containing a number of contingencies – one task depending on the completion of another task – reviewing and monitoring the plan is critical during implementation.
But…
Every project manager that I have ever spoken with agrees that the project plan is MOST important during the initial planning parts of the project.
Dwight Eisenhower once said:
“In preparing for battle I have always found that plans are useless, but planning is indispensable.”
I can’t really compare managing a custom software development project to a ‘battle’, but General Eisenhower makes a good point here which we should all pay attention to.
To emphasize the point: if you don’t understand that you really, really need a good definition of the requirements, go back and read the entry titled “Defining Requirements” again.
The Project Plan
Once you have a good definition of the requirements, a detailed project plan should be developed for the purpose of creating the cost and schedule quotations for the custom software development project. I have had particular success using the Microsoft Project program for creating such quotes. No doubt other software packages that can also do the job. Regardless of the software package you use, it should be able to implement the elements listed below.
Project plans have many uses. One of those uses is to track the progress of the project as it is implemented. Particularly in projects containing a number of contingencies – one task depending on the completion of another task – reviewing and monitoring the plan is critical during implementation.
But…
Every project manager that I have ever spoken with agrees that the project plan is MOST important during the initial planning parts of the project.
Dwight Eisenhower once said:
“In preparing for battle I have always found that plans are useless, but planning is indispensable.”
I can’t really compare managing a custom software development project to a ‘battle’, but General Eisenhower makes a good point here which we should all pay attention to.
Friday, March 20, 2009
The Software Requirements Specification (SRS)
The requirements for the project must be defined in detail. A specification is the proper method for providing this definition. Such a specification is sometimes called a “Statement of Work” or a “Functional Specification”. Most often, however, it is called a “Software Requirements Specification" (or SRS) so that is the name that I will use.
As you can tell from the previous discussion, the SRS performs basically the same function as an RFP. In other words, it is a product or a deliverable. As such, it is only reasonable that the customer pay for it. Once they have that specification, they could present it to competing software development firms.
The successful custom software development companies that I worked for were able to get their customers to understand this concept. The unsuccessful companies, on the other hand, were not able to get their customers to understand this paradigm.
Sophisticated customers who are experienced with developing custom applications will have no problem understanding the need for a good definition of the requirements for the project before the work is done.
Less sophisticated customers may not understand how important such a detailed definition for the solution to be delivered. If you are dealing with such a customer my recommendation is that you try to find someone on the customer’s staff that has a technical background. If such a person exists, I would use that person as an ally to talk to the main customer about the need for detailed description.
If you cannot find such an ally, I recommend a face-to-face meeting which includes a presentation of standard project management methodologies – all of which emphasize how important it is to define the requirements.
If the customer is still unconvinced, you should seriously consider dropping the project. I have worked with such customers and they are the ones who continuously ask for and expect without charge “scope creep” enhancements. Such customers are difficult to manage and are difficult to work with profitably.
However, regardless of whether or not you are able to convince your customers to pay for the SRS, that specification should have these characteristics:
1. The SRS should be well organized with numbered sections and/or paragraph numbers. This makes it much easier to go immediately to the proper location in the specification when you are reviewing it with the customer. This also makes it easier to relate the contents of the SRS with the detailed project plan.
2. There should be a new version number assigned to every copy of the SRS that is viewed by the customer, beginning with version 1.0. You should always have the technical staff review the SRS before it is sent to the customer and it makes sense to assign version numbers to these copies as well as to the copy sent to the customer. But the very first version that the customer sees should always be ‘1.0’. If some other number is used the customer will be confused. I recommend that internally reviewed copies of the SRS begin with version numbers such as ‘0.8’ or ‘0.9’.
3. You should use active verbs when writing the spec. You should say, “The system will do” rather than “ will be done by the system”. This is just a good practice to use when writing a specification.
You should put into the SRS mock-ups of the Graphical User Interface (GUI) screens that will be used when the solution is implemented. Particularly when dealing with unsophisticated customers, this is truly a case where a picture is worth a thousand words.
4. Show as much detail as possible. For example, if the solution is to include reports, you should document the complete specifications for the reports.
To further elaborate on this detail, there are three pieces of information that need to be specified for any report.
First, each report has some selection criteria which is generally entered by the operator. Often that criterion includes a date range. Or it may include a customer code that allows the report to be run for a single customer (or facility, or vendor, or user, etc.) This is where the GUI interface mock-up in the SRS is most valuable.
Second, the specification for the report should document how the data is to be sorted. This is often independent of the selection criteria but on occasion the selection criterion allows the operator to select how the information to be included in the report is to be sorted. For example, in an Aging Report for an Accounts Receivable application you may wish to see all open invoices that are more than 30 days past their billing date. That is the data that is to be selected for inclusion in the report. But once that data is selected, it is normally grouped by customer so that all of the open invoices for each customer are listed together.
Third, the specification for each report should show the detailed information to be shown for each record in the report. Continuing with the example of an Aging Report, the record for each open invoice should include at a minimum the invoice number, billing date and amount. Each group of invoices for a particular customer should show contact information for that customer (generally someone in the Accounts Receivable department who can talk about any open invoices).
Such detail will allow the customer to understand how to use the report and it will also tell the programmer how to develop the code for the report.
Version Control
The latest version of the SRS should always be an accurate description of the current software that has been delivered to the customer. Whenever a modification is made to the software that reflects a functional change that represents a new capability the SRS should be updated to reflect that modification.
Examples:
1. A new report is added
2. A GUI is modified (a screenshot of the new GUI should be included in the modified specification)
3. The software is updated to work on a new version of an operating system.
The version number of the SRS should be modified with each such change. There should be a table within the SRS, preferably towards the front of the document that shows a history of changes. Each row in that table should include: the new version number, the date the change was made, who updated the SRS (it should be the project manager at the time) and a brief description of the change(s).
Some people, particularly attorneys in my own experience, like to have changes tracked within the document. I’m not a fan of doing this. I believe that the document becomes almost unreadable eventually.
Instead, the software vendor should use the same version control software that they are using for the source code itself. The SRS should be included in that database. That version control software will allow the latest version, as well as any of the earlier versions, of the specification to be easily retrieved.
As you can tell from the previous discussion, the SRS performs basically the same function as an RFP. In other words, it is a product or a deliverable. As such, it is only reasonable that the customer pay for it. Once they have that specification, they could present it to competing software development firms.
The successful custom software development companies that I worked for were able to get their customers to understand this concept. The unsuccessful companies, on the other hand, were not able to get their customers to understand this paradigm.
Sophisticated customers who are experienced with developing custom applications will have no problem understanding the need for a good definition of the requirements for the project before the work is done.
Less sophisticated customers may not understand how important such a detailed definition for the solution to be delivered. If you are dealing with such a customer my recommendation is that you try to find someone on the customer’s staff that has a technical background. If such a person exists, I would use that person as an ally to talk to the main customer about the need for detailed description.
If you cannot find such an ally, I recommend a face-to-face meeting which includes a presentation of standard project management methodologies – all of which emphasize how important it is to define the requirements.
If the customer is still unconvinced, you should seriously consider dropping the project. I have worked with such customers and they are the ones who continuously ask for and expect without charge “scope creep” enhancements. Such customers are difficult to manage and are difficult to work with profitably.
However, regardless of whether or not you are able to convince your customers to pay for the SRS, that specification should have these characteristics:
1. The SRS should be well organized with numbered sections and/or paragraph numbers. This makes it much easier to go immediately to the proper location in the specification when you are reviewing it with the customer. This also makes it easier to relate the contents of the SRS with the detailed project plan.
2. There should be a new version number assigned to every copy of the SRS that is viewed by the customer, beginning with version 1.0. You should always have the technical staff review the SRS before it is sent to the customer and it makes sense to assign version numbers to these copies as well as to the copy sent to the customer. But the very first version that the customer sees should always be ‘1.0’. If some other number is used the customer will be confused. I recommend that internally reviewed copies of the SRS begin with version numbers such as ‘0.8’ or ‘0.9’.
3. You should use active verbs when writing the spec. You should say, “The system will do
You should put into the SRS mock-ups of the Graphical User Interface (GUI) screens that will be used when the solution is implemented. Particularly when dealing with unsophisticated customers, this is truly a case where a picture is worth a thousand words.
4. Show as much detail as possible. For example, if the solution is to include reports, you should document the complete specifications for the reports.
To further elaborate on this detail, there are three pieces of information that need to be specified for any report.
First, each report has some selection criteria which is generally entered by the operator. Often that criterion includes a date range. Or it may include a customer code that allows the report to be run for a single customer (or facility, or vendor, or user, etc.) This is where the GUI interface mock-up in the SRS is most valuable.
Second, the specification for the report should document how the data is to be sorted. This is often independent of the selection criteria but on occasion the selection criterion allows the operator to select how the information to be included in the report is to be sorted. For example, in an Aging Report for an Accounts Receivable application you may wish to see all open invoices that are more than 30 days past their billing date. That is the data that is to be selected for inclusion in the report. But once that data is selected, it is normally grouped by customer so that all of the open invoices for each customer are listed together.
Third, the specification for each report should show the detailed information to be shown for each record in the report. Continuing with the example of an Aging Report, the record for each open invoice should include at a minimum the invoice number, billing date and amount. Each group of invoices for a particular customer should show contact information for that customer (generally someone in the Accounts Receivable department who can talk about any open invoices).
Such detail will allow the customer to understand how to use the report and it will also tell the programmer how to develop the code for the report.
Version Control
The latest version of the SRS should always be an accurate description of the current software that has been delivered to the customer. Whenever a modification is made to the software that reflects a functional change that represents a new capability the SRS should be updated to reflect that modification.
Examples:
1. A new report is added
2. A GUI is modified (a screenshot of the new GUI should be included in the modified specification)
3. The software is updated to work on a new version of an operating system.
The version number of the SRS should be modified with each such change. There should be a table within the SRS, preferably towards the front of the document that shows a history of changes. Each row in that table should include: the new version number, the date the change was made, who updated the SRS (it should be the project manager at the time) and a brief description of the change(s).
Some people, particularly attorneys in my own experience, like to have changes tracked within the document. I’m not a fan of doing this. I believe that the document becomes almost unreadable eventually.
Instead, the software vendor should use the same version control software that they are using for the source code itself. The SRS should be included in that database. That version control software will allow the latest version, as well as any of the earlier versions, of the specification to be easily retrieved.
Understand the technology to be used when making a proposal
I will repeat this many times, the most important rule in developing custom software solutions is:
Deliver the least expensive solution that does the job.
If you provide more technology than the customer needs, the customer will end up paying for more than they need. One of the primary ways of reducing cost when developing software solutions is by reusing previously developed code. But that, by definition, means using technologies that have been used before.
But that rule is a little overly simplistic. Technology changes over time. Computer software technologies change much faster than others. Moreover, the customer has reason to expect that what you deliver will not include Windows 3.11 as the operating system when that OS hasn’t been supported by Microsoft for more than a couple of decades.
Another factor can be found within your technical staff. Software developers like change. They would be very unhappy if they couldn’t learn new technologies as they work.
So how do you tell when to switch technologies?
The most important factor is the customer. Most customers are sophisticated enough to understand the advantages of new computer technologies as they become available. Especially if you are responding to an RFP, the customer may very well specify the technology that should be used.
For less sophisticated customers, the software vendor may have to explain the advantages of new technologies. All new technologies have built-in advantages; though developing something new in those technologies will often cost more than developing the solution in an older technology – particularly if a similar solution has already been developed in that older technology. The software vendor (i.e. the project manager) needs to be aware of the trade-offs and be able to explain them to the customer, if the customer does not already know what they are.
Deliver the least expensive solution that does the job.
If you provide more technology than the customer needs, the customer will end up paying for more than they need. One of the primary ways of reducing cost when developing software solutions is by reusing previously developed code. But that, by definition, means using technologies that have been used before.
But that rule is a little overly simplistic. Technology changes over time. Computer software technologies change much faster than others. Moreover, the customer has reason to expect that what you deliver will not include Windows 3.11 as the operating system when that OS hasn’t been supported by Microsoft for more than a couple of decades.
Another factor can be found within your technical staff. Software developers like change. They would be very unhappy if they couldn’t learn new technologies as they work.
So how do you tell when to switch technologies?
The most important factor is the customer. Most customers are sophisticated enough to understand the advantages of new computer technologies as they become available. Especially if you are responding to an RFP, the customer may very well specify the technology that should be used.
For less sophisticated customers, the software vendor may have to explain the advantages of new technologies. All new technologies have built-in advantages; though developing something new in those technologies will often cost more than developing the solution in an older technology – particularly if a similar solution has already been developed in that older technology. The software vendor (i.e. the project manager) needs to be aware of the trade-offs and be able to explain them to the customer, if the customer does not already know what they are.
Subscribe to:
Posts (Atom)