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.
Understanding the customer - how well does the customer understand the problem
I think a true story will best illustrate the potential problem here.
When I was a self-employed consultant, I was hired to develop a PC-based Purchase Order tracking system for a small distributor close to my office. I worked with the manager of the group that handled the incoming purchase orders - and only that manager. I asked if I could talk to the people who reported to him and actually processed those purchase orders (in other words, the people who would be the actual users of the program), but he said that they were too busy to help define the requirements for the computer program and that talking to them was unnecessary because he understood the process in sufficient detail to define the requirements
After our discussion, I completed the specification, I reviewed it with the manager who then approved it and I developed the software to match what was written in the specification.
Then it became time to install the application and train the users. I trained the users individually (there were only three of them), but as I did so each of them made this comment: “This isn’t going to help us. It has nothing to do with how we handle purchase orders.”
Based on those comments, I called a meeting with the manager and the users and we found out that – basically – the manager had no idea what the people who reported to him actually did, at least not in any level of detail.
After talking to the actual users, I modified the specification so that it more closely matched the processes that they used. I then provided a quotation to the manager to make the necessary changes to match that spec. The manager acknowledged his mistakes, but he also did not have the authority to get additional funding. Or, more likely, if he asked his own manager for the money, he would have to admit his mistake. So, instead of authorizing me to make those changes, he said that he would get his users to use the program as I developed it. I don’t believe that they ever really used the program.
That is an extreme example, but it illustrates the point.
A more realistic example would be a customer requiring a web-based application, and knowing that they need to encrypt data as it is sent over the Internet, but not knowing whether Secure Socket Layer (SSL) – the most common methodology for encrypting data - is adequate for the customer’s needs. Some customers will understand SSL. Some won’t.
The most important things to learn from the customer are:
1. What is the problem that the computer system is intended to solve
2. What are the current processes (if any) currently used to address that problem.
In some cases the customer will think that they know the answers but don’t. If at all possible, talk to the users who actually implement whatever process is currently being used.
If the customer is ISO-9000 certified, they will have well documented processes. But even then you should review the processes with the users to insure that the processes are accurate. (I know that they are supposed to be accurate because that is what ISO-9000 is supposed to guarantee and the processes should be audited periodically. But some companies are more rigid about following the actual processes than others are. The users who do the work will know.)
When I was a self-employed consultant, I was hired to develop a PC-based Purchase Order tracking system for a small distributor close to my office. I worked with the manager of the group that handled the incoming purchase orders - and only that manager. I asked if I could talk to the people who reported to him and actually processed those purchase orders (in other words, the people who would be the actual users of the program), but he said that they were too busy to help define the requirements for the computer program and that talking to them was unnecessary because he understood the process in sufficient detail to define the requirements
After our discussion, I completed the specification, I reviewed it with the manager who then approved it and I developed the software to match what was written in the specification.
Then it became time to install the application and train the users. I trained the users individually (there were only three of them), but as I did so each of them made this comment: “This isn’t going to help us. It has nothing to do with how we handle purchase orders.”
Based on those comments, I called a meeting with the manager and the users and we found out that – basically – the manager had no idea what the people who reported to him actually did, at least not in any level of detail.
After talking to the actual users, I modified the specification so that it more closely matched the processes that they used. I then provided a quotation to the manager to make the necessary changes to match that spec. The manager acknowledged his mistakes, but he also did not have the authority to get additional funding. Or, more likely, if he asked his own manager for the money, he would have to admit his mistake. So, instead of authorizing me to make those changes, he said that he would get his users to use the program as I developed it. I don’t believe that they ever really used the program.
That is an extreme example, but it illustrates the point.
A more realistic example would be a customer requiring a web-based application, and knowing that they need to encrypt data as it is sent over the Internet, but not knowing whether Secure Socket Layer (SSL) – the most common methodology for encrypting data - is adequate for the customer’s needs. Some customers will understand SSL. Some won’t.
The most important things to learn from the customer are:
1. What is the problem that the computer system is intended to solve
2. What are the current processes (if any) currently used to address that problem.
In some cases the customer will think that they know the answers but don’t. If at all possible, talk to the users who actually implement whatever process is currently being used.
If the customer is ISO-9000 certified, they will have well documented processes. But even then you should review the processes with the users to insure that the processes are accurate. (I know that they are supposed to be accurate because that is what ISO-9000 is supposed to guarantee and the processes should be audited periodically. But some companies are more rigid about following the actual processes than others are. The users who do the work will know.)
Understanding the customer: the level of sophistication
The issue here is whether or not the customer truly understands the need to define in detail the requirements for the software solution ahead of time.
To a great extent, this determination is based on the size and importance of the project. Customers, who want a large custom software project implemented, will assign individuals on their side who have a great deal of understanding and experience in such projects. This may very well include people with advanced degrees in computer science.
For smaller projects, this is not always the case.
Software – especially the custom variety - is still a new enough product that many customers, especially smaller ones, are not very sophisticated about what is needed in order to provide a proper solution. They have a tendency to believe that custom software solutions are not very much different from standard solutions. You buy Microsoft Word if you want to write letters. You buy a different type of standard solution – customized appropriately – if you want to, for example, have an automated manufacturing system.
I once worked with a customer who knew that off-the-shelf software (products such as MS Word) could be purchased for just a few hundred dollars. That customer asked why custom software should cost thousands of dollars.
Most customers aren't that unsophisticated. Hopefully the sales staff will have answered questions such as that before the technical people get in touch with them.
To a great extent, this determination is based on the size and importance of the project. Customers, who want a large custom software project implemented, will assign individuals on their side who have a great deal of understanding and experience in such projects. This may very well include people with advanced degrees in computer science.
For smaller projects, this is not always the case.
Software – especially the custom variety - is still a new enough product that many customers, especially smaller ones, are not very sophisticated about what is needed in order to provide a proper solution. They have a tendency to believe that custom software solutions are not very much different from standard solutions. You buy Microsoft Word if you want to write letters. You buy a different type of standard solution – customized appropriately – if you want to, for example, have an automated manufacturing system.
I once worked with a customer who knew that off-the-shelf software (products such as MS Word) could be purchased for just a few hundred dollars. That customer asked why custom software should cost thousands of dollars.
Most customers aren't that unsophisticated. Hopefully the sales staff will have answered questions such as that before the technical people get in touch with them.
Requests for Proposals (RFPs)
An RFP is issued by the customer. The customer announces that they have written an RFP because they need a new system of some type. For example, one of the states in the United States will announce that they need a new system for issuing driver’s licenses. Included in the announcement will be instructions about how to get a copy of the detailed RFP.
Once that announcement has been made, any vendors potentially interested in responding to the RFP can request a copy.
The RFP is a very detailed description of what the custom solution that the customer wants should include. I have personally read RFPs that run to more than 400 pages. Vendors are allowed to ask questions in writing about the contents of the RFP, which will be answered as long as the administrative rules for submitting questions specified in the RFP are met. Most often the questions asked by one vendor and answered by the customer will be shared with the other vendors. Fundamentally the RFP is intended to be the technical specification for the new solution and generally serves that purpose well.
It should be pointed out that the proposal submitted in response to the RFP must include costs as well as a description of the solution that the customer is to provide.
In most RFPs, much of the text is non-technical. For example, some of it will be a description of the process that vendors are to use when responding to the RFP with a quotation.
The point of this section is to say that if you are responding to an RFP, what follows in the rest of this discussion on defining requirements is really irrelevant. The RFP defines the requirements without the other steps mentioned on this blog.
Having said that, I will mention that if your proposal is accepted, some customers are open to having discussions on modifications to the proposal on the condition that you can show a cost savings or you can propose an addition to the requirements that you can demonstrate will pay for itself in a relatively short period of time. If the customer is open to such a discussion then much of the advice about the definition of requirements becomes relevant again.
Once that announcement has been made, any vendors potentially interested in responding to the RFP can request a copy.
The RFP is a very detailed description of what the custom solution that the customer wants should include. I have personally read RFPs that run to more than 400 pages. Vendors are allowed to ask questions in writing about the contents of the RFP, which will be answered as long as the administrative rules for submitting questions specified in the RFP are met. Most often the questions asked by one vendor and answered by the customer will be shared with the other vendors. Fundamentally the RFP is intended to be the technical specification for the new solution and generally serves that purpose well.
It should be pointed out that the proposal submitted in response to the RFP must include costs as well as a description of the solution that the customer is to provide.
In most RFPs, much of the text is non-technical. For example, some of it will be a description of the process that vendors are to use when responding to the RFP with a quotation.
The point of this section is to say that if you are responding to an RFP, what follows in the rest of this discussion on defining requirements is really irrelevant. The RFP defines the requirements without the other steps mentioned on this blog.
Having said that, I will mention that if your proposal is accepted, some customers are open to having discussions on modifications to the proposal on the condition that you can show a cost savings or you can propose an addition to the requirements that you can demonstrate will pay for itself in a relatively short period of time. If the customer is open to such a discussion then much of the advice about the definition of requirements becomes relevant again.
Defining Requirements
Any discussion on the subject of managing software development will spend many words emphasizing the importance of defining the requirements for the software before the software is developed. All of them will say that requirement definitiion is the key to successfully managing the development of software projects.
They’re all right. It is the most important aspect of successful software development.
Probably the single most significant area in which custom software development differs from standard software development is in the definition of requirements.
With standard software development, requirements should be defined based on the advice of the marketing group. The marketers should talk to the customers or the potential customers and find out what they are looking for in some software. If the marketing people talk to ten customers and nine of them say that they are more likely to buy the software if it has a particular feature, then you add that feature. On the other hand, if none of the customer wants a feature you don’t add it. If some relatively small, but non-zero, percentage of customers claim that they are more likely to buy your software if it has a particular feature, you do an evaluation of the cost of adding that feature relative to the additional revenue likely to be realized by adding that feature.
This is an obvious process to use. It is amazing that it is not always used.
I worked for a few years for a company that basically allowed the programmers to decide the features to be included in their standard software. The company had a very week marketing department, so the programmers read the software literature and added the newest and greatest bells and whistles they found there, without really any regard as to whether or not any customers really wanted those features. Of course, some of the features they added were things that the customers actually wanted. But the customers had no particular desire for some of the other features that the programmers added. A lot of the cost of developing new features was invested in things that didn't add any sales revenue. Of course, as new features are added the software becomes more complex. The more complex it is, the harder it is to test. Very complex software sometimes requires test cases that are not actually used. The bottom line is that extra features may lower the reliability of the software. If those features do not result in increased revenue, then they should be avoided.
If you invest enough resources into the development, you will add a sufficient number of features to get some software sales. But if those features are not things that your customers are really looking for, then you are probably not going to make much of a profit while you are doing so.
This company sold hardware as well as software and the availability of the standard software improved hardware sales so the company remained profitable (mainly from the sales of their hardware). But they always missed their software profitability goals. This was particularly frustrating because the company’s competitors made more profit on their software than they did on their hardware.
It appears that their competitors actually talked to their customers before investing their resources into a new product.
As important as talking to the customer is when developing a standard software product, it is critical when defining requirements for a custom software solution. The reason that customers purchase a custom software solution is to efficiently and effectively solve a problem that they are experiencing. Therefore it is absolutely necessary for those who are developing that solution to understand the customer’s problem.
We will now discuss the specific steps that should be taken in order to effectively define the requirements of custom software projects.
They’re all right. It is the most important aspect of successful software development.
Probably the single most significant area in which custom software development differs from standard software development is in the definition of requirements.
With standard software development, requirements should be defined based on the advice of the marketing group. The marketers should talk to the customers or the potential customers and find out what they are looking for in some software. If the marketing people talk to ten customers and nine of them say that they are more likely to buy the software if it has a particular feature, then you add that feature. On the other hand, if none of the customer wants a feature you don’t add it. If some relatively small, but non-zero, percentage of customers claim that they are more likely to buy your software if it has a particular feature, you do an evaluation of the cost of adding that feature relative to the additional revenue likely to be realized by adding that feature.
This is an obvious process to use. It is amazing that it is not always used.
I worked for a few years for a company that basically allowed the programmers to decide the features to be included in their standard software. The company had a very week marketing department, so the programmers read the software literature and added the newest and greatest bells and whistles they found there, without really any regard as to whether or not any customers really wanted those features. Of course, some of the features they added were things that the customers actually wanted. But the customers had no particular desire for some of the other features that the programmers added. A lot of the cost of developing new features was invested in things that didn't add any sales revenue. Of course, as new features are added the software becomes more complex. The more complex it is, the harder it is to test. Very complex software sometimes requires test cases that are not actually used. The bottom line is that extra features may lower the reliability of the software. If those features do not result in increased revenue, then they should be avoided.
If you invest enough resources into the development, you will add a sufficient number of features to get some software sales. But if those features are not things that your customers are really looking for, then you are probably not going to make much of a profit while you are doing so.
This company sold hardware as well as software and the availability of the standard software improved hardware sales so the company remained profitable (mainly from the sales of their hardware). But they always missed their software profitability goals. This was particularly frustrating because the company’s competitors made more profit on their software than they did on their hardware.
It appears that their competitors actually talked to their customers before investing their resources into a new product.
As important as talking to the customer is when developing a standard software product, it is critical when defining requirements for a custom software solution. The reason that customers purchase a custom software solution is to efficiently and effectively solve a problem that they are experiencing. Therefore it is absolutely necessary for those who are developing that solution to understand the customer’s problem.
We will now discuss the specific steps that should be taken in order to effectively define the requirements of custom software projects.
Wednesday, March 18, 2009
A project manager must be a good problem solver/Good planner
If you wanted to summarize a good project manager in a single short phrase, I believe that phrase would be: problem solver.
At every stage, projects have problems (or opportunities as some say). The good project managers are those who can keep the project moving along by solving those problems.
Having said that, clearly it is also true that the best projects have fewer problems than the projects which are not-so-good. The best way to minimize the number of problems is by planning for them. So, working hand-in-hand with the ability to solve problems is the ability to plan the project well enough that problems don’t occur in the first place. The two skills are nearly inseparable. I have known successful project managers who are good planners but less skillful at solving problems. I also know of successful project manager who are rotten at planning but can quickly solve every problem that comes around.
The members of the project team generally prefer the better planners, unless they really crave excitement.
Not surprisingly the very best project managers have both skills. They plan well and they can quickly solve the relatively few problems which, inevitably, do surface.
Much of the rest of this book focuses on planning the project (getting the requirements together and documenting them well, planning resources and so on). So in this section of the book, I will focus on problem solving.
One of the keys to good problem solving is simply knowing who knows what. In particular it is important to know who the experts are – particularly who are the experts that you can trust. If you have a database question, who is the best person to ask about databases? If you have a network problem, who is the best person to ask about networks?
These experts don’t necessarily have to be people working on your project, though that would be ideal. However if the expert is not working on your project, you need to understand that the expert’s time is valuable and you should treat it as such. But most people don’t mind offering advice when someone seeks them out as an expert. That sort of advice can help start the problem solving in the right direction and often requires only a few minutes of discussion in order to get some beginning advice. If you are completely unfamiliar with a particular problem that arises, it is good to at least get an initial assessment of whether or not the problem is serious or not.
This is another reason why it is good to have technical project managers. Sometimes they can act as their own problem-solving experts. But, in general, for many reasons, the best plan is to involve the project team in developing solutions to problems.
Some technical problems lend themselves to very obvious solutions. But even those obvious solutions may require extra analysis.
I worked for a while for a company that was investing millions of dollars in a new “standard” software program which replaced an older existing program. The software architects decided to use something called an “object-oriented database”. That database made it easier to develop code. The problem was that the database did not scale well. In other words as the database got larger and larger the performance suffered considerably.
Initially there were no real performance issues. Then when problems with performance started to appear as more data was added to the database, an obvious solution was selected: buy faster and faster hardware. Eventually, every couple of months, they were buying the best and fastest processor and system that they could find and were reconfiguring it and doing their testing on that system. They were fighting a losing battle, of course. Over time, even on their state-of-the-art machines, the new software systems were taking more than a day to perform operations that took the older system less than an hour to perform using much slower hardware. Ultimately the designers chose the only possible alternative – redesign the system with a different type of database (i.e. one that was not object-oriented). Unfortunately the type of database in use was a key part of every software component so the software was delayed by over a year and millions of dollars were lost. (A number of people lost their jobs as well.)
In retrospect, the change of database designs should have been made earlier in the development process. The initial decision to simply continuously select newer and faster software should have been done only after much more analysis which should have begun at least when the problem was first detected. In this specific instance, I would blame the project manager more than I would the software architects for not making the decision to change the design earlier. I wouldn’t necessarily blame the project manager for the initial decision to use an object-oriented database. There probably should have been some questions asked about performance before the design was completed because the technical specification included some performance goals. But once the problem was identified, it was important to come up with the best solution that would not have caused so much time and money to be wasted. Simply buying faster and faster hardware was easy and relatively straightforward, but it was not that “best” solution.
As an aside, in this specific example, the project manager may have to take more of the responsibility than in other technical designs. I’ve already emphasized the need for project managers on technical projects to have a good technical background of their own. But I don’t believe that it is necessary for the project manager to be the best technical person working on the project. To some extent the project manager really does have to depend on his or her technical staff to make the best technical decisions.
But an object-oriented database was a new technology which had not been used before on any project developed at that particular company. As such the use of such a database should have been recognized as a significant risk. Because of that risk the project manager should have initiated some research by the project team, particularly the project team leads, to see what problems may be associated with that new technology. Talking to other customers of that database product is a good first step but there are other ways to do such research. While things have changed quite a bit in the last decade since this situation first arose, the inability of these databases to scale as the amount of data contained in them increases should have been apparent early in that research. The problem could have –and should have – been identified before it was first used as a component in the design.
Custom software projects often don’t have the luxury of performing such research. It costs time and money which can cut directly into the profit margins of the project itself. Because of that it often a good idea to be very cautious when implementing new technologies in custom software projects. Fortunately it is often the case that the customer will make recommendations of the technology that they would like to use. If a new technology is recommended, then the customer implicitly assumes a portion of the risk of using that new technology.
That’s all fine and good. But, if a problem has not been discovered until after development was begun, how should that problem be handled?
In the object-oriented-database example, once it was discovered that the performance of the system was not matching the specifications, the project team should have done an analysis. (In this example they didn’t really analyze the reasons for the bad performance; instead they just figured that faster hardware would solve the problem. Temporarily, at least, it did. But the improvements in hardware performance did not keep pace with the need for faster hardware which was based on the number of objects in the database.)
The analysis should have compared the previous system design with the new design. The comparison should have recognized that the difference was due to a lack of performance in the database. The database, as a single component, could then have been tested under more and more stringent conditions and found not to scale well.
Note that testing such as I suggest doesn’t generally take a great deal of time or effort. System bottlenecks tend to be pretty obvious and generally don’t change much.
How do you solve problems such as this?
There are many methods which people use to solve problems. There are also many different types of problems which can appear on projects. On some projects there may be non-technical problems such as an unresponsive customer. Or you may have two project team members who don’t work well with each other because of some personality conflict.
But the most common problems are technical, so I would prefer to focus the discussion on those.
The best way to solve a technical problem is with the help of the technical team. Some people only like to engage the help of the technical leads on the project. If the problem is relatively minor, that’s probably the best way to handle it. It doesn’t make much sense to involve the entire technical staff in resolving every problem.
But with a larger problem, such as the object-oriented database problem described previously, I much prefer to ask for the ideas of the entire technical team, or at least those individuals involved in the specific area where the problem is occurring. I doubt, for example, that I would get the hardware engineers involved in solving a software problem, though I might even do that under special circumstances.
But when solving a problem, unless the solution is very obvious (such as insufficient test data provided by the customer) the more ideas you have the better. Often the first idea discussed may not provide the solution but it may stimulate another idea which turns out to be the best solution.
Additionally, for the major problems, it may very well have been the project leads whose designs caused the problem in the first place.
If at all possible I also prefer to get the ideas and opinions of how to solve a particular problem in an informal and private environment. As we found out when discussing the personalities of software developers, they tend to be very introverted. Many of them might be unwilling to express their opinion in a large group, particularly if it is critical and may cause some conflict between individuals. But if you talk to them privately and in a non-confrontational manner, you are much more likely to get honest suggestions for solutions.
Hopefully, after talking with the members of the project team, one or more ideas for solutions to the current problem will have been suggested. If none of the ideas seem to be adequate or you have no ideas at all, then the search needs to be extended beyond the members of the project team. In such a case, you could ask for the opinion of others within your company who are working on similar projects or you could hire an outside consultant to help provide possible solutions. (The outside consultant could be expensive and could also, quite possibly, take quite a while to understand the problem well enough to offer possible solutions.)
Once you have a list of possible solutions, you should analyze them for ease (i.e. expense) of implementation and risk. This is another example of an instance where having a project manager with a technical background helps when managing technical projects.
Then discuss them in a meeting with the project team.
The meeting should be open and frank with everyone invited who contributed a possible solution for the problem. Some attempts should be made to quantify the effects on cost and schedule for implementing each of the proposed solution. If any changes to the technical requirements (i.e. the “spec”) would be required, those should be identified as well.
At this point in this discussion, it is important to remember that when a serious problem which needs correction occurs on a project, in nearly every case a compromise of some type must be made with the three key project deliverables: specification, schedule and budget. Often, in fact, more than one of those deliverables will have to be compromised.
Such problems do occur on almost any project. That’s why contingency should be built into the project plan for both schedule and budget (even occasionally for specification). Even when you do that, there are times that the technical problems exceed the planned for contingency.
On a custom software project, I contend that the least important factor is budget. If you can deliver a solution that meets schedule and specification then the customer will probably come back to you for future enhancements. There’s a good chance that you’ll get the money back in the long run. However if you do something to make the customer unhappy with what you’ve delivered, you’ve severely hurt your long-term relationship with that customer.
In the example of the poorly performing, object-oriented database problem that I described earlier.
Clearly the second time through the process you should do some testing.
At every stage, projects have problems (or opportunities as some say). The good project managers are those who can keep the project moving along by solving those problems.
Having said that, clearly it is also true that the best projects have fewer problems than the projects which are not-so-good. The best way to minimize the number of problems is by planning for them. So, working hand-in-hand with the ability to solve problems is the ability to plan the project well enough that problems don’t occur in the first place. The two skills are nearly inseparable. I have known successful project managers who are good planners but less skillful at solving problems. I also know of successful project manager who are rotten at planning but can quickly solve every problem that comes around.
The members of the project team generally prefer the better planners, unless they really crave excitement.
Not surprisingly the very best project managers have both skills. They plan well and they can quickly solve the relatively few problems which, inevitably, do surface.
Much of the rest of this book focuses on planning the project (getting the requirements together and documenting them well, planning resources and so on). So in this section of the book, I will focus on problem solving.
One of the keys to good problem solving is simply knowing who knows what. In particular it is important to know who the experts are – particularly who are the experts that you can trust. If you have a database question, who is the best person to ask about databases? If you have a network problem, who is the best person to ask about networks?
These experts don’t necessarily have to be people working on your project, though that would be ideal. However if the expert is not working on your project, you need to understand that the expert’s time is valuable and you should treat it as such. But most people don’t mind offering advice when someone seeks them out as an expert. That sort of advice can help start the problem solving in the right direction and often requires only a few minutes of discussion in order to get some beginning advice. If you are completely unfamiliar with a particular problem that arises, it is good to at least get an initial assessment of whether or not the problem is serious or not.
This is another reason why it is good to have technical project managers. Sometimes they can act as their own problem-solving experts. But, in general, for many reasons, the best plan is to involve the project team in developing solutions to problems.
Some technical problems lend themselves to very obvious solutions. But even those obvious solutions may require extra analysis.
I worked for a while for a company that was investing millions of dollars in a new “standard” software program which replaced an older existing program. The software architects decided to use something called an “object-oriented database”. That database made it easier to develop code. The problem was that the database did not scale well. In other words as the database got larger and larger the performance suffered considerably.
Initially there were no real performance issues. Then when problems with performance started to appear as more data was added to the database, an obvious solution was selected: buy faster and faster hardware. Eventually, every couple of months, they were buying the best and fastest processor and system that they could find and were reconfiguring it and doing their testing on that system. They were fighting a losing battle, of course. Over time, even on their state-of-the-art machines, the new software systems were taking more than a day to perform operations that took the older system less than an hour to perform using much slower hardware. Ultimately the designers chose the only possible alternative – redesign the system with a different type of database (i.e. one that was not object-oriented). Unfortunately the type of database in use was a key part of every software component so the software was delayed by over a year and millions of dollars were lost. (A number of people lost their jobs as well.)
In retrospect, the change of database designs should have been made earlier in the development process. The initial decision to simply continuously select newer and faster software should have been done only after much more analysis which should have begun at least when the problem was first detected. In this specific instance, I would blame the project manager more than I would the software architects for not making the decision to change the design earlier. I wouldn’t necessarily blame the project manager for the initial decision to use an object-oriented database. There probably should have been some questions asked about performance before the design was completed because the technical specification included some performance goals. But once the problem was identified, it was important to come up with the best solution that would not have caused so much time and money to be wasted. Simply buying faster and faster hardware was easy and relatively straightforward, but it was not that “best” solution.
As an aside, in this specific example, the project manager may have to take more of the responsibility than in other technical designs. I’ve already emphasized the need for project managers on technical projects to have a good technical background of their own. But I don’t believe that it is necessary for the project manager to be the best technical person working on the project. To some extent the project manager really does have to depend on his or her technical staff to make the best technical decisions.
But an object-oriented database was a new technology which had not been used before on any project developed at that particular company. As such the use of such a database should have been recognized as a significant risk. Because of that risk the project manager should have initiated some research by the project team, particularly the project team leads, to see what problems may be associated with that new technology. Talking to other customers of that database product is a good first step but there are other ways to do such research. While things have changed quite a bit in the last decade since this situation first arose, the inability of these databases to scale as the amount of data contained in them increases should have been apparent early in that research. The problem could have –and should have – been identified before it was first used as a component in the design.
Custom software projects often don’t have the luxury of performing such research. It costs time and money which can cut directly into the profit margins of the project itself. Because of that it often a good idea to be very cautious when implementing new technologies in custom software projects. Fortunately it is often the case that the customer will make recommendations of the technology that they would like to use. If a new technology is recommended, then the customer implicitly assumes a portion of the risk of using that new technology.
That’s all fine and good. But, if a problem has not been discovered until after development was begun, how should that problem be handled?
In the object-oriented-database example, once it was discovered that the performance of the system was not matching the specifications, the project team should have done an analysis. (In this example they didn’t really analyze the reasons for the bad performance; instead they just figured that faster hardware would solve the problem. Temporarily, at least, it did. But the improvements in hardware performance did not keep pace with the need for faster hardware which was based on the number of objects in the database.)
The analysis should have compared the previous system design with the new design. The comparison should have recognized that the difference was due to a lack of performance in the database. The database, as a single component, could then have been tested under more and more stringent conditions and found not to scale well.
Note that testing such as I suggest doesn’t generally take a great deal of time or effort. System bottlenecks tend to be pretty obvious and generally don’t change much.
How do you solve problems such as this?
There are many methods which people use to solve problems. There are also many different types of problems which can appear on projects. On some projects there may be non-technical problems such as an unresponsive customer. Or you may have two project team members who don’t work well with each other because of some personality conflict.
But the most common problems are technical, so I would prefer to focus the discussion on those.
The best way to solve a technical problem is with the help of the technical team. Some people only like to engage the help of the technical leads on the project. If the problem is relatively minor, that’s probably the best way to handle it. It doesn’t make much sense to involve the entire technical staff in resolving every problem.
But with a larger problem, such as the object-oriented database problem described previously, I much prefer to ask for the ideas of the entire technical team, or at least those individuals involved in the specific area where the problem is occurring. I doubt, for example, that I would get the hardware engineers involved in solving a software problem, though I might even do that under special circumstances.
But when solving a problem, unless the solution is very obvious (such as insufficient test data provided by the customer) the more ideas you have the better. Often the first idea discussed may not provide the solution but it may stimulate another idea which turns out to be the best solution.
Additionally, for the major problems, it may very well have been the project leads whose designs caused the problem in the first place.
If at all possible I also prefer to get the ideas and opinions of how to solve a particular problem in an informal and private environment. As we found out when discussing the personalities of software developers, they tend to be very introverted. Many of them might be unwilling to express their opinion in a large group, particularly if it is critical and may cause some conflict between individuals. But if you talk to them privately and in a non-confrontational manner, you are much more likely to get honest suggestions for solutions.
Hopefully, after talking with the members of the project team, one or more ideas for solutions to the current problem will have been suggested. If none of the ideas seem to be adequate or you have no ideas at all, then the search needs to be extended beyond the members of the project team. In such a case, you could ask for the opinion of others within your company who are working on similar projects or you could hire an outside consultant to help provide possible solutions. (The outside consultant could be expensive and could also, quite possibly, take quite a while to understand the problem well enough to offer possible solutions.)
Once you have a list of possible solutions, you should analyze them for ease (i.e. expense) of implementation and risk. This is another example of an instance where having a project manager with a technical background helps when managing technical projects.
Then discuss them in a meeting with the project team.
The meeting should be open and frank with everyone invited who contributed a possible solution for the problem. Some attempts should be made to quantify the effects on cost and schedule for implementing each of the proposed solution. If any changes to the technical requirements (i.e. the “spec”) would be required, those should be identified as well.
At this point in this discussion, it is important to remember that when a serious problem which needs correction occurs on a project, in nearly every case a compromise of some type must be made with the three key project deliverables: specification, schedule and budget. Often, in fact, more than one of those deliverables will have to be compromised.
Such problems do occur on almost any project. That’s why contingency should be built into the project plan for both schedule and budget (even occasionally for specification). Even when you do that, there are times that the technical problems exceed the planned for contingency.
On a custom software project, I contend that the least important factor is budget. If you can deliver a solution that meets schedule and specification then the customer will probably come back to you for future enhancements. There’s a good chance that you’ll get the money back in the long run. However if you do something to make the customer unhappy with what you’ve delivered, you’ve severely hurt your long-term relationship with that customer.
In the example of the poorly performing, object-oriented database problem that I described earlier.
Clearly the second time through the process you should do some testing.
A good project manager must be a good communicator
The project manager will be working with three different stakeholders: the customer, the development team and his managers. Each group requires nearly constant communication. But each group has a diverse set of interests and priorities as well as different levels of technical knowledge.
Surely it is true that all three groups have an interest in meeting all three of the project goals of specification, schedule and budget. But each group would prioritize those three goals somewhat differently.
If the customer is paying for the solution on a Time and Materials basis, cost will be the highest priority. But in my own experience, most of the time, the customer is offered a fixed cost estimate. In those cases, the customer understandably loses much of their interest in managing the cost. Instead they focus on the technical features (which I call the “spec”) and the schedule. The importance of those two things is relatively equivalent to most customers, but of those two things, I believe the schedule is often the higher priority.
First of all, often the customer representative who you are communicating with is another project manager. That person is responsible for the same things that the vendor’s project manager is responsible for: spec, schedule and budget. Therefore the customer’s own project manager is making commitments to his or her own managers and other stakeholders that are based on the commitments that you are making. The most visible of those commitments is the schedule.
That’s because changes to the schedule will cost the customer money. They may have to get their technical staff to plan for some infrastructure changes in order to implement the solution and they have to make the users of the new solution available for training. Often that means changing the hours that those users can support production with the older system. Sometimes it even means completely shutting down production with the older solution. Such things require notification and planning. Delays cause extra expenses.
So while the customer surely wants the solution to work with all of the agreed upon features, it is often the case that the customer will delay the inclusion of some features, particularly if the missing features are not key features for the application, as long as the solution can begin to be used when scheduled.
The second stakeholder is the technical team. Their main concern is most often meeting the technical specification. Their job is primarily to make it work. Moreover, that’s what they enjoy doing. Budget and schedule – while surely important and the programmers understand that – are secondary to them. They may actually try to provide more than the customer needs or even wants as long as the challenge of providing those features is interesting to them. (By the way, this is one of the reasons that it is good for the project manager to have a technical background. It is easier for a technical project manager to recognize when the programmers are adding things into the development that really aren’t needed. Note that not all features that programmers add are obvious to the user.)
The final stakeholder is the project manager’s management. The technical specs are the least important feature to them, though the managers understand the need to meet the specs. Instead their primary interest in that regard is whether or not the customer will accept the solution. Schedule is slightly more important. A delayed schedule means delaying the movement of the members of the technical staff working on this project over to another project.
But their main concern, in my own experience, is nearly always cost. Which makes complete sense, of course. After all, if you are not making money on your projects you can’t stay in business very long.
So the project manager must effectively communicate with all of these stakeholders, each of which are emphasizing different aspects of the project. But the forms of communication are different.
The overriding and most important document is the SRS. It has to be written in a way that it can be understood by the customer as well as the development team. That is a difficult but achievable task.
Customers also want to have periodic status updates. These must be based on input from the development team. On large projects weekly conference calls are the most effective way of doing this. Individual developers can participate, but as long as the project manager is able to understand the status, their participation is not necessary.
On smaller as well as larger projects, I recommend keeping an issues list. Any issues that the customer raises should be included. Issues raised by others, particularly the development staff, don’t necessarily need to be on the list that is shared with the customer. That is not to imply that you should keep secrets from the customer. Instead it means that some things raised by the development staff may be more technical than the customer has any interest in.
This issues list that you review with the customer should have the following characteristics:
1. An issue number. This allows easy reference to each specific issue.
2. A short name for each issue. This is another way to reference each issue, which is another way to make those issues easier to remember. (The customer may remember what “issue number 24” is, but they are more likely to remember a name like “Long search times”.)
3. The date that the issue was added to the list.
4. The person who raised the issue.
5. A longer description of the issue.
6. The person who is assigned to resolve the issue. Often this is the project manager. If the issue reflects a problem with some portion of the code, the issue may be assigned to the programmer who wrote that section of code.
7. A history of what has happened on this issue. This narrative will be added to over time and can become quite long. If attempts are made to resolve the issue which are unsuccessful, that historical information should be tracked as well. It is best that the person assigned to resolve the issue update this section of the issues list. However the project manager can do it as well.
8. The date that the issue was closed (if it is closed). Note that if the customer is involved, then the customer must agree that the issue has been closed. A date in this column means that the issue has been closed and need not be discussed when reviewing issues.
When communicating with the customer, it is important to do so in ways other than strictly through emails and other written mechanisms. Surely email messages have their place, particularly when exchanging electronic documents. But oral communications help immensely when creating a relationship with a customer.
That relationship is very important.
Communicating with the software development team is more a matter of listening than anything else. You should always remember that you are dealing with a group of people who tend to be very introverted. One-on-one communication often works best.
However you do it, you need to sense frustration, conflict but also be able to follow the progress of the project. If the team is going in non-productive directions (generally when they are trying to implement new state-of-the-art techniques that may be more than the customer needs) you need to be able to understand and step in. It is good to have periodic project status and schedule review meetings (generally weekly), but it is also a good idea to meet with at least the key members of the project team informally more often. I generally try to spend at least five minutes with each key team member every day.
The amount of communication that you have to do with your managers depends on the importance of the project, the stage in the project’s development that you are at and, in some cases, the amount of trouble that the project may be in.
Early in most projects, particularly when you are developing the requirements for the project, your managers may not show much interest. They will have an interest in the schedule and cost of the project, but the technical requirements of custom software projects are of much less interest to them. As you begin the implementation of such projects, however, if the project is important the level of interest of your managers will rise significantly over time.
On very important projects, your management is going to want to be included on project status reviews. They will probably wish to participate in the status reviews done with the customer. Certainly you should expect to update them on project status at least once a week.
If everything on the project is going well, the level of interest of your managers in the project will not exceed such weekly meetings. That is, of course, another reason why early in a project the level of interest of your managers will be relatively minor.
But if the project does start to fall behind on schedule or budget (and less importantly on spec) the level of the managers to whom you will have to report will increase. I’ve always considered it to be somewhat ironic that important projects that are in a bit of trouble require more and more reporting which effectively helps to remove the people who can solve the problems from operating in that role.
Surely it is true that all three groups have an interest in meeting all three of the project goals of specification, schedule and budget. But each group would prioritize those three goals somewhat differently.
If the customer is paying for the solution on a Time and Materials basis, cost will be the highest priority. But in my own experience, most of the time, the customer is offered a fixed cost estimate. In those cases, the customer understandably loses much of their interest in managing the cost. Instead they focus on the technical features (which I call the “spec”) and the schedule. The importance of those two things is relatively equivalent to most customers, but of those two things, I believe the schedule is often the higher priority.
First of all, often the customer representative who you are communicating with is another project manager. That person is responsible for the same things that the vendor’s project manager is responsible for: spec, schedule and budget. Therefore the customer’s own project manager is making commitments to his or her own managers and other stakeholders that are based on the commitments that you are making. The most visible of those commitments is the schedule.
That’s because changes to the schedule will cost the customer money. They may have to get their technical staff to plan for some infrastructure changes in order to implement the solution and they have to make the users of the new solution available for training. Often that means changing the hours that those users can support production with the older system. Sometimes it even means completely shutting down production with the older solution. Such things require notification and planning. Delays cause extra expenses.
So while the customer surely wants the solution to work with all of the agreed upon features, it is often the case that the customer will delay the inclusion of some features, particularly if the missing features are not key features for the application, as long as the solution can begin to be used when scheduled.
The second stakeholder is the technical team. Their main concern is most often meeting the technical specification. Their job is primarily to make it work. Moreover, that’s what they enjoy doing. Budget and schedule – while surely important and the programmers understand that – are secondary to them. They may actually try to provide more than the customer needs or even wants as long as the challenge of providing those features is interesting to them. (By the way, this is one of the reasons that it is good for the project manager to have a technical background. It is easier for a technical project manager to recognize when the programmers are adding things into the development that really aren’t needed. Note that not all features that programmers add are obvious to the user.)
The final stakeholder is the project manager’s management. The technical specs are the least important feature to them, though the managers understand the need to meet the specs. Instead their primary interest in that regard is whether or not the customer will accept the solution. Schedule is slightly more important. A delayed schedule means delaying the movement of the members of the technical staff working on this project over to another project.
But their main concern, in my own experience, is nearly always cost. Which makes complete sense, of course. After all, if you are not making money on your projects you can’t stay in business very long.
So the project manager must effectively communicate with all of these stakeholders, each of which are emphasizing different aspects of the project. But the forms of communication are different.
The overriding and most important document is the SRS. It has to be written in a way that it can be understood by the customer as well as the development team. That is a difficult but achievable task.
Customers also want to have periodic status updates. These must be based on input from the development team. On large projects weekly conference calls are the most effective way of doing this. Individual developers can participate, but as long as the project manager is able to understand the status, their participation is not necessary.
On smaller as well as larger projects, I recommend keeping an issues list. Any issues that the customer raises should be included. Issues raised by others, particularly the development staff, don’t necessarily need to be on the list that is shared with the customer. That is not to imply that you should keep secrets from the customer. Instead it means that some things raised by the development staff may be more technical than the customer has any interest in.
This issues list that you review with the customer should have the following characteristics:
1. An issue number. This allows easy reference to each specific issue.
2. A short name for each issue. This is another way to reference each issue, which is another way to make those issues easier to remember. (The customer may remember what “issue number 24” is, but they are more likely to remember a name like “Long search times”.)
3. The date that the issue was added to the list.
4. The person who raised the issue.
5. A longer description of the issue.
6. The person who is assigned to resolve the issue. Often this is the project manager. If the issue reflects a problem with some portion of the code, the issue may be assigned to the programmer who wrote that section of code.
7. A history of what has happened on this issue. This narrative will be added to over time and can become quite long. If attempts are made to resolve the issue which are unsuccessful, that historical information should be tracked as well. It is best that the person assigned to resolve the issue update this section of the issues list. However the project manager can do it as well.
8. The date that the issue was closed (if it is closed). Note that if the customer is involved, then the customer must agree that the issue has been closed. A date in this column means that the issue has been closed and need not be discussed when reviewing issues.
When communicating with the customer, it is important to do so in ways other than strictly through emails and other written mechanisms. Surely email messages have their place, particularly when exchanging electronic documents. But oral communications help immensely when creating a relationship with a customer.
That relationship is very important.
Communicating with the software development team is more a matter of listening than anything else. You should always remember that you are dealing with a group of people who tend to be very introverted. One-on-one communication often works best.
However you do it, you need to sense frustration, conflict but also be able to follow the progress of the project. If the team is going in non-productive directions (generally when they are trying to implement new state-of-the-art techniques that may be more than the customer needs) you need to be able to understand and step in. It is good to have periodic project status and schedule review meetings (generally weekly), but it is also a good idea to meet with at least the key members of the project team informally more often. I generally try to spend at least five minutes with each key team member every day.
The amount of communication that you have to do with your managers depends on the importance of the project, the stage in the project’s development that you are at and, in some cases, the amount of trouble that the project may be in.
Early in most projects, particularly when you are developing the requirements for the project, your managers may not show much interest. They will have an interest in the schedule and cost of the project, but the technical requirements of custom software projects are of much less interest to them. As you begin the implementation of such projects, however, if the project is important the level of interest of your managers will rise significantly over time.
On very important projects, your management is going to want to be included on project status reviews. They will probably wish to participate in the status reviews done with the customer. Certainly you should expect to update them on project status at least once a week.
If everything on the project is going well, the level of interest of your managers in the project will not exceed such weekly meetings. That is, of course, another reason why early in a project the level of interest of your managers will be relatively minor.
But if the project does start to fall behind on schedule or budget (and less importantly on spec) the level of the managers to whom you will have to report will increase. I’ve always considered it to be somewhat ironic that important projects that are in a bit of trouble require more and more reporting which effectively helps to remove the people who can solve the problems from operating in that role.
A Project Manager should have good technical abilities
It is very important that the Project Manager for custom software development projects have technical experience; i.e. have programming experience. In fact, if possible, that manager should have a good understanding of the particular technology being used in the project.
The project manager should be the person who works with the customer in order to define the requirements of the project. If that person does not understand the technology being used they will not recognize where there are possible tradeoffs.
Allow me to provide an example.
In the early 1980’s, I worked on a project that was a joint venture with another company based in California. The project was to develop an automated system for testing the heads and disks used in computer hard drives.
Some of the specifications for heads and disks include requirements for things like signal-to-noise ratio and something called “peak shift” which could be best measured by expensive instruments purchased from a third-party. Five instruments costing a total of more than $100,000 were required for the complete suite of tests that needed to be performed. However, no two instruments were used at the same time. In addition some time was spent replacing the head or disk being tested with another production unit. This included the time required for the disk to get up to speed and then stopped. The bottom line was that each of these expensive instruments was sitting idle at least 80% of the time.
A more efficient way to utilize those expensive instruments was to share them among multiple “test stands” containing heads and disks. In that way the utilization of the instruments could be increased significantly. When one of the instruments had completed testing on one test stand, it could be switched over to run that same test on one of the other stands. Moreover the instruments could still be utilized while one of the heads or disks had completed testing and was being replaced.
I managed the project to develop something that we called an “Instrument Bay Controller” (or IBC). The other company developed the test stands where the heads and disks were mounted for testing.
One of the issues that came up is which sort of computer-to-computer communications should be used. Two alternatives were considered: RS-232 and Ethernet. (These can be explained in more common terms by comparing them to methods of connecting to the Internet. RS-232 is the method used for dial-up. Ethernet is the method used for high-speed connections.)
Note that this decision was made about 25 years ago. At that time, the hardware for an RS-232 connection cost $75 per connection. An Ethernet board cost $2000 per connection. In other words, connecting two computers together required two boards – one in each of the computers. So the cost of that connection would be $150 using RS-232 but $4000 using Ethernet instead. There are other costs as well. For example, Ethernet cables were considerably more expensive than RS-232 cables, though that cost difference has gone down considerably. Also because Ethernet technology was relatively new at the time, a larger amount of software development was required to implement it.
I knew two things that affected the decision. First all of the messages exchanged between computers were relatively short with a maximum length of 20 characters. I also knew that the disks were spinning at 3600 RPM which meant that any single revolution of the disk took 16.7 milliseconds. Any message between computers that took less than 16.7 milliseconds to transfer would not impact the overall throughput. RS-232 could exchange such short messages within that window of time.
The company that we were partnering with wanted to use Ethernet. I recommended RS-232. We arrived at a compromise where either could be used. When we put the system into production at our company, we used RS-232. Our partner used Ethernet.
Why did the other company decide to use Ethernet?
The decision was made primarily because their entire technical team recommended Ethernet. I personally believe that they made that recommendation precisely because Ethernet was the state-of-the-art. They all lived and worked in Silicon Valley and, as superficial a reason as this might be, they wanted to be able to tell their peers that they were using Ethernet. Certainly Ethernet has technical advantages over RS-232 (just as high-speed Internet connectivity has advantages over dial-up) and those technical advantages were described in detail to the managers at the other company who made the final decision on which technology to use. However because those managers never understood the actual design, then didn’t understand that in this application there was no real advantage. So that lack of technical understanding cost the company many thousands of dollars.
It is worth noting that about two years later we added Ethernet to the IBC because we needed to send the test data to a database server so that the test results could be analyzed in detail. However by then the cost of Ethernet had come down considerably. Also the technical advantages of Ethernet became very relevant: the messages had many more characters in them and the database server was very far away from the location where the testing was done so that RS-232 simply wouldn’t have worked. But we never had to use Ethernet as the communication methodology for communicating between the IBC and the test stands.
Though it is more of an example of a hardware tradeoff than a software tradeoff, I think that it does demonstrate how important it is for the project manager to have a technical background in order to make the best decisions.
In addition to understanding the tradeoffs better if you have a technical background, if the project manager has to ask a technical member of the project team every single time the customer asks a technical question, the customer will start to lose confidence in the project manager. Surely the project manager shouldn’t be expected to answer every single technical question asked by the customer, and in many cases before the project manager answers the question he or she should say something about confirming the accuracy of the answer with the technical team. But if the project manager can demonstrate to the customer a good understanding of the technical issues of the project, the relationship between the customer and the project manager will improve. Lacking such a level of technical ability, I’ve seen instances where a customer has started to contact members of the technical staff directly without involving the project manager.
That is the path to chaos. If the customer is contacting the developers directly, that customer could be hearing commitments and getting answers to questions that reflect real scope changes in the customer’s expectations of what the solution will ultimately contain. Clearly that should never be allowed. But the customer will be tempted to follow that path if they need an immediate answer to a question and they don’t have confidence that the project manager can provide that answer.
A technical understanding is a valuable asset with any level of management within a software development company. This goes all the way up to the top of the organization.
Joel Spolsky is a software developer, living in New York, who writes about software development, management and business on the Internet. Mr. Spolsky says this:
“If you ask me, and I’m biased, no software company can succeed unless there is a programmer at the helm.”
I wouldn’t go that far. I think that managers who are not technical but willing to take advice of technical people can certainly succeed.
But I certainly think that it is difficult for a software project to succeed without a technical person, particularly a programmer, leading it. (But then, like Mr. Spolsky, I may also be a bit biased.)
The project manager should be the person who works with the customer in order to define the requirements of the project. If that person does not understand the technology being used they will not recognize where there are possible tradeoffs.
Allow me to provide an example.
In the early 1980’s, I worked on a project that was a joint venture with another company based in California. The project was to develop an automated system for testing the heads and disks used in computer hard drives.
Some of the specifications for heads and disks include requirements for things like signal-to-noise ratio and something called “peak shift” which could be best measured by expensive instruments purchased from a third-party. Five instruments costing a total of more than $100,000 were required for the complete suite of tests that needed to be performed. However, no two instruments were used at the same time. In addition some time was spent replacing the head or disk being tested with another production unit. This included the time required for the disk to get up to speed and then stopped. The bottom line was that each of these expensive instruments was sitting idle at least 80% of the time.
A more efficient way to utilize those expensive instruments was to share them among multiple “test stands” containing heads and disks. In that way the utilization of the instruments could be increased significantly. When one of the instruments had completed testing on one test stand, it could be switched over to run that same test on one of the other stands. Moreover the instruments could still be utilized while one of the heads or disks had completed testing and was being replaced.
I managed the project to develop something that we called an “Instrument Bay Controller” (or IBC). The other company developed the test stands where the heads and disks were mounted for testing.
One of the issues that came up is which sort of computer-to-computer communications should be used. Two alternatives were considered: RS-232 and Ethernet. (These can be explained in more common terms by comparing them to methods of connecting to the Internet. RS-232 is the method used for dial-up. Ethernet is the method used for high-speed connections.)
Note that this decision was made about 25 years ago. At that time, the hardware for an RS-232 connection cost $75 per connection. An Ethernet board cost $2000 per connection. In other words, connecting two computers together required two boards – one in each of the computers. So the cost of that connection would be $150 using RS-232 but $4000 using Ethernet instead. There are other costs as well. For example, Ethernet cables were considerably more expensive than RS-232 cables, though that cost difference has gone down considerably. Also because Ethernet technology was relatively new at the time, a larger amount of software development was required to implement it.
I knew two things that affected the decision. First all of the messages exchanged between computers were relatively short with a maximum length of 20 characters. I also knew that the disks were spinning at 3600 RPM which meant that any single revolution of the disk took 16.7 milliseconds. Any message between computers that took less than 16.7 milliseconds to transfer would not impact the overall throughput. RS-232 could exchange such short messages within that window of time.
The company that we were partnering with wanted to use Ethernet. I recommended RS-232. We arrived at a compromise where either could be used. When we put the system into production at our company, we used RS-232. Our partner used Ethernet.
Why did the other company decide to use Ethernet?
The decision was made primarily because their entire technical team recommended Ethernet. I personally believe that they made that recommendation precisely because Ethernet was the state-of-the-art. They all lived and worked in Silicon Valley and, as superficial a reason as this might be, they wanted to be able to tell their peers that they were using Ethernet. Certainly Ethernet has technical advantages over RS-232 (just as high-speed Internet connectivity has advantages over dial-up) and those technical advantages were described in detail to the managers at the other company who made the final decision on which technology to use. However because those managers never understood the actual design, then didn’t understand that in this application there was no real advantage. So that lack of technical understanding cost the company many thousands of dollars.
It is worth noting that about two years later we added Ethernet to the IBC because we needed to send the test data to a database server so that the test results could be analyzed in detail. However by then the cost of Ethernet had come down considerably. Also the technical advantages of Ethernet became very relevant: the messages had many more characters in them and the database server was very far away from the location where the testing was done so that RS-232 simply wouldn’t have worked. But we never had to use Ethernet as the communication methodology for communicating between the IBC and the test stands.
Though it is more of an example of a hardware tradeoff than a software tradeoff, I think that it does demonstrate how important it is for the project manager to have a technical background in order to make the best decisions.
In addition to understanding the tradeoffs better if you have a technical background, if the project manager has to ask a technical member of the project team every single time the customer asks a technical question, the customer will start to lose confidence in the project manager. Surely the project manager shouldn’t be expected to answer every single technical question asked by the customer, and in many cases before the project manager answers the question he or she should say something about confirming the accuracy of the answer with the technical team. But if the project manager can demonstrate to the customer a good understanding of the technical issues of the project, the relationship between the customer and the project manager will improve. Lacking such a level of technical ability, I’ve seen instances where a customer has started to contact members of the technical staff directly without involving the project manager.
That is the path to chaos. If the customer is contacting the developers directly, that customer could be hearing commitments and getting answers to questions that reflect real scope changes in the customer’s expectations of what the solution will ultimately contain. Clearly that should never be allowed. But the customer will be tempted to follow that path if they need an immediate answer to a question and they don’t have confidence that the project manager can provide that answer.
A technical understanding is a valuable asset with any level of management within a software development company. This goes all the way up to the top of the organization.
Joel Spolsky is a software developer, living in New York, who writes about software development, management and business on the Internet. Mr. Spolsky says this:
“If you ask me, and I’m biased, no software company can succeed unless there is a programmer at the helm.”
I wouldn’t go that far. I think that managers who are not technical but willing to take advice of technical people can certainly succeed.
But I certainly think that it is difficult for a software project to succeed without a technical person, particularly a programmer, leading it. (But then, like Mr. Spolsky, I may also be a bit biased.)
It's possible to have too much education
"Too much" education is a characteristic that is really more applicable to custom software development than it is to standard software development.
If you review the definitions of standard and custom software Standard software programs provide the basis for the custom software development. Not all standard software requires customization. Game software, for example, isn’t customizable.
In other words, people buy standard software because of how “cool” it is.
People buy custom software because it solves a specific problem. Customers want that problem solved, but they want it solved efficiently – i.e. they want it to work, but they want it to work cheaply.
People with advanced degrees in fields like Computer Science are really good at making things “cool”. They are knowledgeable in the latest and greatest trends and techniques in the computer industry and (generally) know how to implement them. So if you are selling something as the “coolest” product on the market, the programmers with the advanced degrees can surely help.
But to the customers of custom projects, “cool” isn’t as important as “cheap”.
My first job after college was working in an instrumentation department for a large manufacturer. (“Instrumentation” is equipment designed to test the products produced by manufacturing.) The instrumentation department consisted of both degreed and non-degreed engineers so I had an opportunity to observe engineers with both types of educational levels.
In all honesty, the non-degreed engineers were better suited to that particular job. Those engineers merely wanted to get something to work. They would start by trying to find something in past designs that worked and reuse that design wherever possible.
At one point an engineer with a Master’s degree was hired to work in the department. That engineer was not content with simply reusing designs that had worked in the past. The new engineer wanted to use the “latest and greatest” techniques and products. Unfortunately those new techniques were more expensive and they also took more time to implement.
The same factors are important in custom software design. While the phrase, “Uses well-tested three-year-old technologies” may not be a very effective sales pitch with standard software, it works very well with custom software.
So the key of custom software (and hardware) is: make it work; the cheaper the better. In my own experience, people with advanced degrees tend to overlook this basic precept.
Having said all of that, I believe that having some formal education in computer programming is very beneficial. I worked with one computer programmer, who actually had an MBA. He was very bright. He had started programming computers as a hobby, and then when he discovered how much he enjoyed it, he changed his job within the company where he worked and went from manager to programmer. However he had never taken a formal course in computer programming. There were many techniques that he didn’t know. For example he had never heard of an “iterative loop” (an “iterative loop” is a block of code within a computer program which is executed repeatedly in order to work on successive parts of a problem resulting in an efficient solution to the problem).
Implications:
A Bachelor’s degree is something to look for in all software development environments. But be suspicious of higher degrees, at least when working on custom software development projects.
If you review the definitions of standard and custom software Standard software programs provide the basis for the custom software development. Not all standard software requires customization. Game software, for example, isn’t customizable.
In other words, people buy standard software because of how “cool” it is.
People buy custom software because it solves a specific problem. Customers want that problem solved, but they want it solved efficiently – i.e. they want it to work, but they want it to work cheaply.
People with advanced degrees in fields like Computer Science are really good at making things “cool”. They are knowledgeable in the latest and greatest trends and techniques in the computer industry and (generally) know how to implement them. So if you are selling something as the “coolest” product on the market, the programmers with the advanced degrees can surely help.
But to the customers of custom projects, “cool” isn’t as important as “cheap”.
My first job after college was working in an instrumentation department for a large manufacturer. (“Instrumentation” is equipment designed to test the products produced by manufacturing.) The instrumentation department consisted of both degreed and non-degreed engineers so I had an opportunity to observe engineers with both types of educational levels.
In all honesty, the non-degreed engineers were better suited to that particular job. Those engineers merely wanted to get something to work. They would start by trying to find something in past designs that worked and reuse that design wherever possible.
At one point an engineer with a Master’s degree was hired to work in the department. That engineer was not content with simply reusing designs that had worked in the past. The new engineer wanted to use the “latest and greatest” techniques and products. Unfortunately those new techniques were more expensive and they also took more time to implement.
The same factors are important in custom software design. While the phrase, “Uses well-tested three-year-old technologies” may not be a very effective sales pitch with standard software, it works very well with custom software.
So the key of custom software (and hardware) is: make it work; the cheaper the better. In my own experience, people with advanced degrees tend to overlook this basic precept.
Having said all of that, I believe that having some formal education in computer programming is very beneficial. I worked with one computer programmer, who actually had an MBA. He was very bright. He had started programming computers as a hobby, and then when he discovered how much he enjoyed it, he changed his job within the company where he worked and went from manager to programmer. However he had never taken a formal course in computer programming. There were many techniques that he didn’t know. For example he had never heard of an “iterative loop” (an “iterative loop” is a block of code within a computer program which is executed repeatedly in order to work on successive parts of a problem resulting in an efficient solution to the problem).
Implications:
A Bachelor’s degree is something to look for in all software development environments. But be suspicious of higher degrees, at least when working on custom software development projects.
Some Programmers are a bit peculiar
Peculiarity isn’t so much of a generality as it is an exception. But it is an exception worth discussing because it really seems to apply more to computer programmers than to non-programmers. This characteristic can best be described through two stories, both of which are completely true.
I have changed the names of these programmers.
I met George in California. He was one of the best programming minds that I’ve ever worked with. George and I worked closely together for a number of months and got to know each other quite well.
However, I learned over time that George had some very different ideas. Even the reason that he became a computer programmer was a bit different.
George grew up in Philadelphia and attended on the Universities there. His major when he started his college education was sculpture. But one rather cold day, he decided to take a shortcut through the computer building on campus. As he was walking down a hallway, he looked into one of the rooms and noticed someone sitting in front of a large, green computer monitor. (George attended college about 35 years ago. That was well before color monitors became prevalent.) At that moment, as he described it to me, he literally had a religious experience. He walked into the room and stood silently behind the person working there and simply stared at the monitor, completely transfixed. The programmer noticed him and they began a conversation. George decided – then and there – to change his major to computer science (a rather dramatic change from sculpture).
An even better example took place one day as we went to lunch together. About halfway through the meal, this conversation took place:
George: “Randy, do you believe that people have auras around them?”
Me: “Well, I’ve Karolin photographs which show auras so, at least for the sake of argument; I’ll agree that people have auras around them.”
George: “Well then, Randy, do you believe that I can see the auras around people?”
Me (smiling): “No, George. I don’t believe that you can see the auras around people.”
George, continuing with no hesitation: “Randy, do you believe that computers have auras around them.”
Me, after a few moments of thought: “Well, there are electromagnetic things going on inside of computers so, sure, once again for the sake of argument, I can agree that computers have auras around them.”
George: “Do you believe that I can see the auras around computers?”
Me (laughing now): “No, George. I definitely do not believe that you can see the auras around computers.”
George: “Well I can. One time I was asked to fix a computer program but the source code for the program had been lost. So all that we had was a thick computer printout containing a binary dump of the program. [A “binary dump” is a listing of the ones-and-zeros that the computer uses for the program. Most initial reactions when looking at such a listing is that it is nothing more than a very long sequence of random numbers.] I looked through the printout and noticed that the aura in one part of the program was different from the aura in the rest of the program. I guessed that was where the bug was located, and I was right!”
At this point, I was laughing hysterically.
But I knew George well enough to know that he was being completely serious. So he, at least believed, that he could see auras in computer printouts.
Even non-programmers have seen computer printouts. I’ve never talked to anyone else who claims to see auras in them.
I have another completely true example.
In one of my jobs, my office was arranged in such a way that my back was to the door of the office. One day, I was reading an article in a technical magazine. I recall that I literally had my feet up on my desk.
I don’t recall what the article was about, but it must have been interesting because I recall reading it without looking up for a fairly long period of time.
When I was done, I glanced at the doorway and noticed Calvin. Calvin wasn’t really in the doorway. He was sort of glancing around the door jam; I could really only see his head. I greeted him and asked him what he wanted. He said that he had a question. We discussed his question for a few minutes and when he was satisfied, he turned to leave.
I then asked him how long he had been waiting to get my attention. He told me he had been waiting for a half-hour!
That’s 30 minutes! I’ve waited that long to have the oil changed in my car and become impatient. Yet Calvin waited that long rather than interrupt someone who had assumed a posture effectively asking to be interrupted.
Was he telling the truth? I have no way of knowing, but I knew Calvin fairly well. He was the meekest, most introverted person I have ever met. So I believe that his time estimate was possibly true.
Like George, Calvin was a very good programmer. He was just a little different.
Implications:
I have a couple of other examples of such behavior. (I knew another talented programmer who had a television but NEVER used it for anything but playing video games.) But I believe that I’ve made my point.
So what does that mean? .
First, you should expect to see the occasional “oddball”. And, I believe, those “oddballs” will tend to be your better programmers. So look for them.
Second, one of the things that interviewers look for when trying to fill an open position is how well the person might fit into the group. This is an important consideration when interviewing software developers. But some behaviors that might raise a red flag in other professions should not necessarily be considered as threatening when interviewing software developers – someone who claims to see auras around other people, computers and even computer printouts may have a problem fitting into a group of insurance adjusters but seems to have no problem fitting into a group of computer programmers. That’s because, such behavior doesn’t really affect their job and it is in the nature of computer programmers to focus on the job. In general such unusual behavior will not bother the other members of the programming staff.
There are things that will bother the other members of the software development team. This might be a good time to discuss those things.
When looking for a good fit, be cautious about people who are reluctant to accept the opinion of others. Some programmers are so confident in their own abilities that they are unwilling to accept some methodology for doing things that is different from their own opinion. Certainly you should listen to their ideas. If a decision is made that goes against their recommendations, the reasons for that decision should be explained. But once such a decision is made, everyone on the project team should be willing to proceed with the development. People who pout because their own recommendation has not been accepted do not fit in very well. In my own experience, people with advanced degrees in Computer Science are most often guilty of this. (See the section on “It’s possible to have too much education”.)
As I mention elsewhere in this book, the best technology to use when writing custom software is the cheapest technology that will solve the problem. That may not be the “coolest” or “latest-and-greatest” technology. If you can’t accept that, don’t work on custom software development.
Of course sometimes the “coolest” technology is the best one to use. That is why custom software developers certainly do need to be kept up-to-date with the latest technology. But that is not always the case and the members of the software development team have to understand this.
I have changed the names of these programmers.
I met George in California. He was one of the best programming minds that I’ve ever worked with. George and I worked closely together for a number of months and got to know each other quite well.
However, I learned over time that George had some very different ideas. Even the reason that he became a computer programmer was a bit different.
George grew up in Philadelphia and attended on the Universities there. His major when he started his college education was sculpture. But one rather cold day, he decided to take a shortcut through the computer building on campus. As he was walking down a hallway, he looked into one of the rooms and noticed someone sitting in front of a large, green computer monitor. (George attended college about 35 years ago. That was well before color monitors became prevalent.) At that moment, as he described it to me, he literally had a religious experience. He walked into the room and stood silently behind the person working there and simply stared at the monitor, completely transfixed. The programmer noticed him and they began a conversation. George decided – then and there – to change his major to computer science (a rather dramatic change from sculpture).
An even better example took place one day as we went to lunch together. About halfway through the meal, this conversation took place:
George: “Randy, do you believe that people have auras around them?”
Me: “Well, I’ve Karolin photographs which show auras so, at least for the sake of argument; I’ll agree that people have auras around them.”
George: “Well then, Randy, do you believe that I can see the auras around people?”
Me (smiling): “No, George. I don’t believe that you can see the auras around people.”
George, continuing with no hesitation: “Randy, do you believe that computers have auras around them.”
Me, after a few moments of thought: “Well, there are electromagnetic things going on inside of computers so, sure, once again for the sake of argument, I can agree that computers have auras around them.”
George: “Do you believe that I can see the auras around computers?”
Me (laughing now): “No, George. I definitely do not believe that you can see the auras around computers.”
George: “Well I can. One time I was asked to fix a computer program but the source code for the program had been lost. So all that we had was a thick computer printout containing a binary dump of the program. [A “binary dump” is a listing of the ones-and-zeros that the computer uses for the program. Most initial reactions when looking at such a listing is that it is nothing more than a very long sequence of random numbers.] I looked through the printout and noticed that the aura in one part of the program was different from the aura in the rest of the program. I guessed that was where the bug was located, and I was right!”
At this point, I was laughing hysterically.
But I knew George well enough to know that he was being completely serious. So he, at least believed, that he could see auras in computer printouts.
Even non-programmers have seen computer printouts. I’ve never talked to anyone else who claims to see auras in them.
I have another completely true example.
In one of my jobs, my office was arranged in such a way that my back was to the door of the office. One day, I was reading an article in a technical magazine. I recall that I literally had my feet up on my desk.
I don’t recall what the article was about, but it must have been interesting because I recall reading it without looking up for a fairly long period of time.
When I was done, I glanced at the doorway and noticed Calvin. Calvin wasn’t really in the doorway. He was sort of glancing around the door jam; I could really only see his head. I greeted him and asked him what he wanted. He said that he had a question. We discussed his question for a few minutes and when he was satisfied, he turned to leave.
I then asked him how long he had been waiting to get my attention. He told me he had been waiting for a half-hour!
That’s 30 minutes! I’ve waited that long to have the oil changed in my car and become impatient. Yet Calvin waited that long rather than interrupt someone who had assumed a posture effectively asking to be interrupted.
Was he telling the truth? I have no way of knowing, but I knew Calvin fairly well. He was the meekest, most introverted person I have ever met. So I believe that his time estimate was possibly true.
Like George, Calvin was a very good programmer. He was just a little different.
Implications:
I have a couple of other examples of such behavior. (I knew another talented programmer who had a television but NEVER used it for anything but playing video games.) But I believe that I’ve made my point.
So what does that mean? .
First, you should expect to see the occasional “oddball”. And, I believe, those “oddballs” will tend to be your better programmers. So look for them.
Second, one of the things that interviewers look for when trying to fill an open position is how well the person might fit into the group. This is an important consideration when interviewing software developers. But some behaviors that might raise a red flag in other professions should not necessarily be considered as threatening when interviewing software developers – someone who claims to see auras around other people, computers and even computer printouts may have a problem fitting into a group of insurance adjusters but seems to have no problem fitting into a group of computer programmers. That’s because, such behavior doesn’t really affect their job and it is in the nature of computer programmers to focus on the job. In general such unusual behavior will not bother the other members of the programming staff.
There are things that will bother the other members of the software development team. This might be a good time to discuss those things.
When looking for a good fit, be cautious about people who are reluctant to accept the opinion of others. Some programmers are so confident in their own abilities that they are unwilling to accept some methodology for doing things that is different from their own opinion. Certainly you should listen to their ideas. If a decision is made that goes against their recommendations, the reasons for that decision should be explained. But once such a decision is made, everyone on the project team should be willing to proceed with the development. People who pout because their own recommendation has not been accepted do not fit in very well. In my own experience, people with advanced degrees in Computer Science are most often guilty of this. (See the section on “It’s possible to have too much education”.)
As I mention elsewhere in this book, the best technology to use when writing custom software is the cheapest technology that will solve the problem. That may not be the “coolest” or “latest-and-greatest” technology. If you can’t accept that, don’t work on custom software development.
Of course sometimes the “coolest” technology is the best one to use. That is why custom software developers certainly do need to be kept up-to-date with the latest technology. But that is not always the case and the members of the software development team have to understand this.
Programmers tend to like change
As we all know the vast majority of people don’t like change. Generally speaking, programmers are an exception to this rule. They tend to embrace change.
Of course, the computer industry itself is constantly changing. Almost any computer-related technology (hardware or software) becomes obsolete within 3-5 years. Sometimes new technologies don’t even last that long. Software developers understand that very well and generally want to keep pace with the technology changes.
Implications:
Keep your programmers up-to-date with the newest technologies. This means sending them to classes. Doing so is important both in order to keep your solutions current as well as keeping your programmers happy.
Back in the days when I was primarily a software developer, I spent a few years working for a consulting firm whose specialty was providing a complete manufacturing facility – including the building itself. The firm had about 200 engineers of whom the majority were structural and mechanical engineers. The electrical engineers were just that – electrical. They were experts in wiring buildings, putting in electrical substations, etc. Less than 10% of the engineers worked in disciplines involving the use of computers in their designs.
The firm was very successful because the paid time of the engineers was over 90% billable. However the firm was very, very reluctant to send the engineers to school. When you are in class, you are not billable.
For the majority of the engineers, this was not a problem. The amount of weight borne by a steel I-beam hasn’t changed for a long time.
But I and the other software developers found this situation to be very frustrating. We knew that our knowledge was becoming obsolete. This caused a large amount of turnover among the software developers. It was the primary reason that I left the company.
The lesson to be learned: keep your programmers up-to-date with the newest technologies.
Of course, the computer industry itself is constantly changing. Almost any computer-related technology (hardware or software) becomes obsolete within 3-5 years. Sometimes new technologies don’t even last that long. Software developers understand that very well and generally want to keep pace with the technology changes.
Implications:
Keep your programmers up-to-date with the newest technologies. This means sending them to classes. Doing so is important both in order to keep your solutions current as well as keeping your programmers happy.
Back in the days when I was primarily a software developer, I spent a few years working for a consulting firm whose specialty was providing a complete manufacturing facility – including the building itself. The firm had about 200 engineers of whom the majority were structural and mechanical engineers. The electrical engineers were just that – electrical. They were experts in wiring buildings, putting in electrical substations, etc. Less than 10% of the engineers worked in disciplines involving the use of computers in their designs.
The firm was very successful because the paid time of the engineers was over 90% billable. However the firm was very, very reluctant to send the engineers to school. When you are in class, you are not billable.
For the majority of the engineers, this was not a problem. The amount of weight borne by a steel I-beam hasn’t changed for a long time.
But I and the other software developers found this situation to be very frustrating. We knew that our knowledge was becoming obsolete. This caused a large amount of turnover among the software developers. It was the primary reason that I left the company.
The lesson to be learned: keep your programmers up-to-date with the newest technologies.
The Productivity of Programmers varies quite a bit
In “The Mythical Man-Month”, Brooks observed that the productivity of different programmers can vary by more than a 10-to-1 factor.
In other words, one programmer will need a week to do what another programmer can accomplish in half-a-day.
I submit that there is no other profession in which there is such an extreme difference in productivity levels.
Moreover – and possibly equally surprisingly – the quality of the more productive programmer will most likely exceed the quality of the less productive programmer! In most professions, if one worker is significantly more productive than another worker you expect that the quality of work will suffer as a result. If one cabinet worker (for example) is twice as productive as another worker, you expect that the faster worker is taking shortcuts. But with computer programmers – generally speaking – the more productive the programmer is, the higher the quality of work that programmer produces.
I actually witnessed an example of this disparity in productivity that is worth sharing.
The example involves string manipulation.
For the less technical readers, a “string” is a block of text. It can vary in length from a null string (which consists of zero characters) to a block of text the length of the book “War and Peace” by Tolstoy.
In the vast majority of cases, a “string” is one or more words that make up a name (e.g. “George W. Bush”), a title and a name (“President George W. Bush), an address (“1600 Pennsylvania Avenue”) or simply represent the name of some “thing” rather than some “one” (“The United States of America”).
Similarly, most strings consist of smaller pieces of information, also considered to be strings. “George W. Bush” consists of a string showing the first name (“George”), a shorter string for the middle initial or name (“W.”) and another string showing the last name (“Bush”, of course).
Most of the information stored in a database is stored as a string. Even information containing only digits is generally stored as a string. For example, zip codes should be stored as strings in databases even though the strings are all digits. This is because of problems handling zip codes beginning with a ‘0’ if those strings are stored as numbers. (Those are easily solvable problems, but there is no need to have those problems at all if the zip codes are stored directly as strings.)
Strings are often “manipulated” in computer software. They are separated into their component parts (first name, middle name, last name) or concatenated (appended one to another) to form larger strings.
Strings are such common variables in computer programs that any – and I mean any – experienced computer programmer will have substantial experience in string manipulation software development.
With that background, I will describe my example of varying productivity.
I discovered, basically by accident, that two programmers working for the same company had both independently solved the same programming problem. But they had done so in significantly different ways and in significantly different amounts of time.
The specific problem to be solved was to write a software procedure (i.e. a block of code that performs a specific operation). That procedure was to take an input string which might be short, but which could also be fairly long, and parse it into somewhere between 1-5 smaller strings of roughly equal size. A minimum size was required for each of the smaller strings. The rules to be applied to each of the smaller strings were the same.
Examples (using country names):
Sweden - parsed into a single string (“Sweden”)
United States of America - parsed into three strings: “United”, ”States of”, “America”
I could go into more details including the maximum lengths for the parsed string outputs from the procedure, but the discussion so far is hopefully sufficient to get an idea of the problem to be solved.
One programmer had written the procedure as an iterative loop (i.e. a loop that ran the same code multiple times with different inputs each time). The loop was run up to five times – once for each of the shorter strings, continuing to loop as long as there was some portion of the input string still to be parsed.
The procedure as written required about 20 lines of code. The programmer said that it took him about two hours to write.
The second programmer had written the procedure to first pull each word (i.e. characters separated by spaces) and put the words into an array, the size of the array depended on the number of words in the input string. (The country name “Sweden” would require a single element array. The name “United States of America” would require a four element array because of the four words making up that name.) Then the individual 1-5 output lines were reconstructed from the array elements. The programmer had a difficult time getting the program to correctly process the indices to each of the array elements, so rather than write the program as a loop, he copied-and-pasted the code for the first line four times, once for each of the other possible lines.
The second procedure took nearly three printed pages of code (probably about 125 lines) and I was told that it took three days to write.
Both procedures were tested and both worked.
However the first programmer produced a working procedure in about 1/12 of the time that it took the other programmer.
Also, by most measures of software quality, the first program was also higher quality.
It was shorter and therefore took fewer resources (such as memory). Because it was shorter it would also run a bit faster (this was a web-based program so that it would have to be downloaded over a network. The shorter the program the less time it takes to download. The differences would be fairly insignificant, but still they would exist).
Most significantly, the first program would be easier to modify and reuse if necessary.
For example, if the requirements changed such that the maximum number of output lines went from five to four, only a single digit would need to be changed in the first program (requiring five minutes of programmer’s time at the most). Only a minimal amount of testing would be required to confirm that the modified program worked correctly.
However, in the second program, if that same change was required, a significant number of lines of code would have to be deleted and some variables within the program would also have to change as well. That would require a couple of hours to change and a lot of different test cases would have to be used to insure that it worked correctly.
This is an example of where one computer programmer created a higher quality program twelve times faster than another programmer. I doubt that similar examples can be found in other professions.
A single example such as this one could be something of an anomaly; sometimes programmers like other people just get “mind-blocks”. In fact the “slower” programmer in this example had the reputation of being one of the better programmers working on the project. Or it could be the case that the first programmer was actually much more efficient than the second programmer.
When managing software development, it is obviously important to know which of your programmers are more productive and which are less productive.
Implications:
When managers first become aware that these productivity differences are real, their inclination is to try to hire only the most productive programmers. While there is nothing wrong with the idea of hiring the most productive people possible, it should be pointed out that even the less productive programmers have a place on development staffs.
I described earlier how programmers tend to like their jobs. But they only like their jobs if those jobs are challenging. When developing a complete solution for a customer, some of those jobs aren’t all that challenging.
For example, an integral part of an accounting program will be an “Aging” report (a report that shows all unpaid invoices more than 30 days old, sorted by customer and then generally by date). If the database design is done well, this is a fairly trivial exercise.
If you give the development to one of the more productive programmers, they will complete it quickly. But they won’t be challenged by the task.
If you give that same programmer a number of such jobs, they will lose interest in the project.
Or – in order to challenge themselves – they will add complexity and complications that aren’t really needed.
Also I have seen many instances where a more productive programmer becomes impatient with a programmer who is somewhat less productive and a personal conflict results. That conflict diminishes their ability to work together.
Even more significantly, I have seen many instances where the more productive programmers have problems relating to users. Even when those programmers don’t have to relate directly to individual users (such as talking to them on the phone) they may not even be able to relate to the users indirectly. The programmer may argue that a problem reported by one (or even more that one) user is simply due to a lack of intelligence or sophistication on the part of the user.
So depending on the other strengths that they bring with them, even lower productivity programmers have their place within a project team,.
It is also important for the programmers to have some sense of their own productivity levels.
Before actually writing the code for a specific task, the programmer should form his or her own estimate of the time that will be required. Depending on the size of the task those estimates may be included in the project plan.
If a programmer begins to work on such a task and about 10% of the allotted time has passed, the programmer should assess his or her progress. If progress on the task is better or roughly equal to the time estimate, the programmer should probably continue down the path that they originally chose.
On the other hand, if the progress seems to be significantly less than expected at that point, I recommend that the programmer first put that particular task away and work on something else for a while. Then when they come back to work on that task, they may be able to look at it with a fresher outlook (helping to eliminate the sort of “mind-block” that I mentioned earlier). In the specific productivity example that I described earlier the second programmer may realize that separating the words into an array was not an efficient way to attack the problem.
Alternatively, if nothing simpler seems to be apparent, I recommend that the programmer do some brain-storming with another programmer and try to determine whether it is the approach or the estimate that should be modified.
In other words, one programmer will need a week to do what another programmer can accomplish in half-a-day.
I submit that there is no other profession in which there is such an extreme difference in productivity levels.
Moreover – and possibly equally surprisingly – the quality of the more productive programmer will most likely exceed the quality of the less productive programmer! In most professions, if one worker is significantly more productive than another worker you expect that the quality of work will suffer as a result. If one cabinet worker (for example) is twice as productive as another worker, you expect that the faster worker is taking shortcuts. But with computer programmers – generally speaking – the more productive the programmer is, the higher the quality of work that programmer produces.
I actually witnessed an example of this disparity in productivity that is worth sharing.
The example involves string manipulation.
For the less technical readers, a “string” is a block of text. It can vary in length from a null string (which consists of zero characters) to a block of text the length of the book “War and Peace” by Tolstoy.
In the vast majority of cases, a “string” is one or more words that make up a name (e.g. “George W. Bush”), a title and a name (“President George W. Bush), an address (“1600 Pennsylvania Avenue”) or simply represent the name of some “thing” rather than some “one” (“The United States of America”).
Similarly, most strings consist of smaller pieces of information, also considered to be strings. “George W. Bush” consists of a string showing the first name (“George”), a shorter string for the middle initial or name (“W.”) and another string showing the last name (“Bush”, of course).
Most of the information stored in a database is stored as a string. Even information containing only digits is generally stored as a string. For example, zip codes should be stored as strings in databases even though the strings are all digits. This is because of problems handling zip codes beginning with a ‘0’ if those strings are stored as numbers. (Those are easily solvable problems, but there is no need to have those problems at all if the zip codes are stored directly as strings.)
Strings are often “manipulated” in computer software. They are separated into their component parts (first name, middle name, last name) or concatenated (appended one to another) to form larger strings.
Strings are such common variables in computer programs that any – and I mean any – experienced computer programmer will have substantial experience in string manipulation software development.
With that background, I will describe my example of varying productivity.
I discovered, basically by accident, that two programmers working for the same company had both independently solved the same programming problem. But they had done so in significantly different ways and in significantly different amounts of time.
The specific problem to be solved was to write a software procedure (i.e. a block of code that performs a specific operation). That procedure was to take an input string which might be short, but which could also be fairly long, and parse it into somewhere between 1-5 smaller strings of roughly equal size. A minimum size was required for each of the smaller strings. The rules to be applied to each of the smaller strings were the same.
Examples (using country names):
Sweden - parsed into a single string (“Sweden”)
United States of America - parsed into three strings: “United”, ”States of”, “America”
I could go into more details including the maximum lengths for the parsed string outputs from the procedure, but the discussion so far is hopefully sufficient to get an idea of the problem to be solved.
One programmer had written the procedure as an iterative loop (i.e. a loop that ran the same code multiple times with different inputs each time). The loop was run up to five times – once for each of the shorter strings, continuing to loop as long as there was some portion of the input string still to be parsed.
The procedure as written required about 20 lines of code. The programmer said that it took him about two hours to write.
The second programmer had written the procedure to first pull each word (i.e. characters separated by spaces) and put the words into an array, the size of the array depended on the number of words in the input string. (The country name “Sweden” would require a single element array. The name “United States of America” would require a four element array because of the four words making up that name.) Then the individual 1-5 output lines were reconstructed from the array elements. The programmer had a difficult time getting the program to correctly process the indices to each of the array elements, so rather than write the program as a loop, he copied-and-pasted the code for the first line four times, once for each of the other possible lines.
The second procedure took nearly three printed pages of code (probably about 125 lines) and I was told that it took three days to write.
Both procedures were tested and both worked.
However the first programmer produced a working procedure in about 1/12 of the time that it took the other programmer.
Also, by most measures of software quality, the first program was also higher quality.
It was shorter and therefore took fewer resources (such as memory). Because it was shorter it would also run a bit faster (this was a web-based program so that it would have to be downloaded over a network. The shorter the program the less time it takes to download. The differences would be fairly insignificant, but still they would exist).
Most significantly, the first program would be easier to modify and reuse if necessary.
For example, if the requirements changed such that the maximum number of output lines went from five to four, only a single digit would need to be changed in the first program (requiring five minutes of programmer’s time at the most). Only a minimal amount of testing would be required to confirm that the modified program worked correctly.
However, in the second program, if that same change was required, a significant number of lines of code would have to be deleted and some variables within the program would also have to change as well. That would require a couple of hours to change and a lot of different test cases would have to be used to insure that it worked correctly.
This is an example of where one computer programmer created a higher quality program twelve times faster than another programmer. I doubt that similar examples can be found in other professions.
A single example such as this one could be something of an anomaly; sometimes programmers like other people just get “mind-blocks”. In fact the “slower” programmer in this example had the reputation of being one of the better programmers working on the project. Or it could be the case that the first programmer was actually much more efficient than the second programmer.
When managing software development, it is obviously important to know which of your programmers are more productive and which are less productive.
Implications:
When managers first become aware that these productivity differences are real, their inclination is to try to hire only the most productive programmers. While there is nothing wrong with the idea of hiring the most productive people possible, it should be pointed out that even the less productive programmers have a place on development staffs.
I described earlier how programmers tend to like their jobs. But they only like their jobs if those jobs are challenging. When developing a complete solution for a customer, some of those jobs aren’t all that challenging.
For example, an integral part of an accounting program will be an “Aging” report (a report that shows all unpaid invoices more than 30 days old, sorted by customer and then generally by date). If the database design is done well, this is a fairly trivial exercise.
If you give the development to one of the more productive programmers, they will complete it quickly. But they won’t be challenged by the task.
If you give that same programmer a number of such jobs, they will lose interest in the project.
Or – in order to challenge themselves – they will add complexity and complications that aren’t really needed.
Also I have seen many instances where a more productive programmer becomes impatient with a programmer who is somewhat less productive and a personal conflict results. That conflict diminishes their ability to work together.
Even more significantly, I have seen many instances where the more productive programmers have problems relating to users. Even when those programmers don’t have to relate directly to individual users (such as talking to them on the phone) they may not even be able to relate to the users indirectly. The programmer may argue that a problem reported by one (or even more that one) user is simply due to a lack of intelligence or sophistication on the part of the user.
So depending on the other strengths that they bring with them, even lower productivity programmers have their place within a project team,.
It is also important for the programmers to have some sense of their own productivity levels.
Before actually writing the code for a specific task, the programmer should form his or her own estimate of the time that will be required. Depending on the size of the task those estimates may be included in the project plan.
If a programmer begins to work on such a task and about 10% of the allotted time has passed, the programmer should assess his or her progress. If progress on the task is better or roughly equal to the time estimate, the programmer should probably continue down the path that they originally chose.
On the other hand, if the progress seems to be significantly less than expected at that point, I recommend that the programmer first put that particular task away and work on something else for a while. Then when they come back to work on that task, they may be able to look at it with a fresher outlook (helping to eliminate the sort of “mind-block” that I mentioned earlier). In the specific productivity example that I described earlier the second programmer may realize that separating the words into an array was not an efficient way to attack the problem.
Alternatively, if nothing simpler seems to be apparent, I recommend that the programmer do some brain-storming with another programmer and try to determine whether it is the approach or the estimate that should be modified.
Programmers tend to be objective about their work
Programmers, as do nearly all human beings, prefer praise over criticism. But a programmer is more willing than people in other professions to objectively consider any criticism given them.
More than anything else, programmers want the respect of their peers. They get that respect by writing programs that work. Computers are the ultimate judge of whether or not their code works. And computers clearly don’t care a whit for anyone’s feelings.
So if the programmer wants to have his code work correctly and the computer won’t say things like, “Good try!” any programmer soon learns to evaluate what they have done as objectively as possible. Objective criticism from other programmers only helps rather than hurts.
At the same time, it is important to point out that programming a computer is a purely intellectual activity. A programmer writing a program is creating something using only words defined by the rules of a particular programming language that they are using. In that sense it is no different from writing a short story. However the primary reader of the words is only a machine: a computer.
But computer programs can be written with style and even elegance. The only problem is that only a very small percentage of people in the world can recognize that style and elegance: other computer programmers. Once you have impressed the computer – by writing a program that actually works as intended – programmers relish being able to impress that select, small audience that can understand the words that they have written and the way that they are written.
As you’ve probably noticed, I’m overstating the case a bit. The vast majority of code written is intended purely to work and nothing more. But I even once heard a programmer describe another programmer’s code as “poetic” (clearly a comment that the average person would probably never make regarding anything about computers). But style is important to them and the admiration of their peers is very important.
Implications:
First, while some sensitivity is always good, programmers respond well to objective and positive criticism. So feel free to use it.
Second, be aware that programmers working on your projects may very well offer criticism to you. Accept it gracefully. They’re only trying to help.
Third, allow free and open communication between the programmers especially using processes like code reviews. It improves the quality and reusability of the overall code and increases the self-confidence of the programmers.
Obviously this is one generality that should be applied more carefully than others. While most programmers really are generally fairly objective and accept criticism well, there are exceptions. You should try to find out who those exceptions are.
More than anything else, programmers want the respect of their peers. They get that respect by writing programs that work. Computers are the ultimate judge of whether or not their code works. And computers clearly don’t care a whit for anyone’s feelings.
So if the programmer wants to have his code work correctly and the computer won’t say things like, “Good try!” any programmer soon learns to evaluate what they have done as objectively as possible. Objective criticism from other programmers only helps rather than hurts.
At the same time, it is important to point out that programming a computer is a purely intellectual activity. A programmer writing a program is creating something using only words defined by the rules of a particular programming language that they are using. In that sense it is no different from writing a short story. However the primary reader of the words is only a machine: a computer.
But computer programs can be written with style and even elegance. The only problem is that only a very small percentage of people in the world can recognize that style and elegance: other computer programmers. Once you have impressed the computer – by writing a program that actually works as intended – programmers relish being able to impress that select, small audience that can understand the words that they have written and the way that they are written.
As you’ve probably noticed, I’m overstating the case a bit. The vast majority of code written is intended purely to work and nothing more. But I even once heard a programmer describe another programmer’s code as “poetic” (clearly a comment that the average person would probably never make regarding anything about computers). But style is important to them and the admiration of their peers is very important.
Implications:
First, while some sensitivity is always good, programmers respond well to objective and positive criticism. So feel free to use it.
Second, be aware that programmers working on your projects may very well offer criticism to you. Accept it gracefully. They’re only trying to help.
Third, allow free and open communication between the programmers especially using processes like code reviews. It improves the quality and reusability of the overall code and increases the self-confidence of the programmers.
Obviously this is one generality that should be applied more carefully than others. While most programmers really are generally fairly objective and accept criticism well, there are exceptions. You should try to find out who those exceptions are.
Programmers tend to be optimistic
If you ask a software developer to estimate the amount of time that will be required for them to develop a piece of software (either large or small), they will almost always give an answer that is too short. If they estimate 40 hours, it may very well end up taking 80.
I believe that the reason for this is precisely because the developers enjoy what they do. When offered an opportunity to do something new, they tend to look with enthusiasm at the challenge but overlook the tedious aspects of developing the new code – things such as testing and bug fixes. The more enthusiastic that a particular programmer is about developing software the more optimistic that he or she will tend to be.
Some developers are capable of giving reliable or even conservative time estimates. Since it varies with the individual only experience working with a particular developer will let you know whether or not to adjust the estimate that you get from them. Often the functional manager of the software development team can offer some advice.
Having said all of that, it is always a good idea to get a time estimate from the programmer who will do the work (if that is possible). Because the productivity of software developers varies so much the programmer is probably the best judge of the amount of effort required to write a particular piece of code (once you’ve factored in their level of optimism). Possibly even more importantly, when the programmer provides the time estimate he or she is also providing an implicit commitment to get the software done within that estimated period of time. If you simply force a commitment on the programmer (“I expect you to get this code done in 40 hours”) some developers will react negatively (“I can’t get it done in that much time”). Since developers tend to be optimistic a more common dialog is one like this:
PM: How long will it take to write this code?
Developer: I would say it will take 40 hours.
PM: So, if I give you 60 hours, there shouldn’t be any problem, right?
Developer: Absolutely not!
Then, if the programmer has worked for 40 hours and sees that the software is not completed yet, they will incentivize themselves to work all that much harder on it.
It you can’t get an estimate directly from the programmer, a good secondary option is the programmer’s manager. In that case the manager is providing the commitment and the manager can provide “incentives” if the developer is not meeting the estimate.
Implications:
Always get a time estimate directly from the programmer or from the programmer’s manager. Unless you have experience with estimates from that individual, don’t trust the initial estimate that you get. Add some hours to it. A good factor for an estimate from a programmer with whom you have never worked before is 50%. That seems high, but it also seems to work.
I believe that the reason for this is precisely because the developers enjoy what they do. When offered an opportunity to do something new, they tend to look with enthusiasm at the challenge but overlook the tedious aspects of developing the new code – things such as testing and bug fixes. The more enthusiastic that a particular programmer is about developing software the more optimistic that he or she will tend to be.
Some developers are capable of giving reliable or even conservative time estimates. Since it varies with the individual only experience working with a particular developer will let you know whether or not to adjust the estimate that you get from them. Often the functional manager of the software development team can offer some advice.
Having said all of that, it is always a good idea to get a time estimate from the programmer who will do the work (if that is possible). Because the productivity of software developers varies so much the programmer is probably the best judge of the amount of effort required to write a particular piece of code (once you’ve factored in their level of optimism). Possibly even more importantly, when the programmer provides the time estimate he or she is also providing an implicit commitment to get the software done within that estimated period of time. If you simply force a commitment on the programmer (“I expect you to get this code done in 40 hours”) some developers will react negatively (“I can’t get it done in that much time”). Since developers tend to be optimistic a more common dialog is one like this:
PM: How long will it take to write this code?
Developer: I would say it will take 40 hours.
PM: So, if I give you 60 hours, there shouldn’t be any problem, right?
Developer: Absolutely not!
Then, if the programmer has worked for 40 hours and sees that the software is not completed yet, they will incentivize themselves to work all that much harder on it.
It you can’t get an estimate directly from the programmer, a good secondary option is the programmer’s manager. In that case the manager is providing the commitment and the manager can provide “incentives” if the developer is not meeting the estimate.
Implications:
Always get a time estimate directly from the programmer or from the programmer’s manager. Unless you have experience with estimates from that individual, don’t trust the initial estimate that you get. Add some hours to it. A good factor for an estimate from a programmer with whom you have never worked before is 50%. That seems high, but it also seems to work.
Programmers tend to enjoy their profession
I’m fascinated by the percentage of computer programmers whose primary hobby is: programming computers! A number of them have web servers in their homes with their own web sites built on them. Generally the sites consist of nothing more than family pictures, stories, vacation accounts and the like.
Similarly, when I first discovered the number solitaire game called Sudoku, I was certain that a large number of computer programmers had powered up their laptops and, simply for their own amusement, written programs in programming languages such as Java Script to both generate and solve Sudoku puzzles. (I know that a few dozen years ago, I surely would have done so.)
The most significant examples are the open source code projects. One such project is LINUX, a UNIX based operating system.
Beginning in about 1970, UNIX was developed by a group of programmers at Bell Labs (the research and development arm of AT&T.) The development of the new Operating System was initiated, at least partly, because a computer game ran too slowly on another computer with a different operating system. The small group of programmers, who did the original development, at first did so without any financial support from Bell Labs.
In other words, they did the development primarily for their own amusement.
Or course, eventually UNIX became a fully-supported product of AT&T with its own large staff of developers.
LINUX is a UNIX-like operating system that has been developed mainly by software developers working on the code in their own free time. According to the Wikipedia entry at http://en.wikipedia.org/wiki/LINUX, in 2001 a study of the most commonly used version of LINUX available at that time was performed. The study found that that particular version of the operating system contained 30 million lines-of-code (the most commonly used measure of the size of a computer program). By one measure this is equivalent to eight thousand man-years of development time, which can be equated to something like $1.08 Billion in monetary terms. In the years since 2001, both the number of lines-of-code and the number of man-hours invested in the project have grown considerably.
Think for a few moments about that - individuals working together to apply some eight thousand man-years of their professional skills in their own free time creating something with intellectual propery worth over a billion dollars! And, of course, those numbers have only gone up in the years since then.
Moreover, many claim that LINUX, particularly as a server operating system, is more robust and reliable than Microsoft Windows. This is clear evidence that the programmers who are freely contributing their time are very serious about what they are doing and are not compromising their professional efforts because they are not being paid for that time..
And the LINUX development is just a miunuscule part of the many hours that programmers spend on their “hobby” – which is the same as their profession.
There are probably other professions in which such a relationship between personal and professional interests exists. I have heard that some auto mechanics buy older card in disrepair and restore them in their spare time.
But such examples are surely the exception rather than the rule. At the other extreme, I’ve never heard of a ditch digger digging ditches as a hobby.
An important and related point is that there is a strong correlation between the skill of any particular programmer and the amount of time that programmer spends coding as a hobby. Really that only makes sense, of course. People tend to have hobbies involving things that they do well.
Implications:
Software developers tend not to mind working extra hours, as long as the work is challenging and they are convinced that the extra hours are important for the project. Because of their attachment to their families there are limits to the amount of extra work that they will do. It helps a great deal if they can work from home.
Furthermore, look for the programmers who have their own web site and who let you know that they write their own programs at home. Those are the programmers more likely to be your most enthusiastic software developers.
Similarly, when I first discovered the number solitaire game called Sudoku, I was certain that a large number of computer programmers had powered up their laptops and, simply for their own amusement, written programs in programming languages such as Java Script to both generate and solve Sudoku puzzles. (I know that a few dozen years ago, I surely would have done so.)
The most significant examples are the open source code projects. One such project is LINUX, a UNIX based operating system.
Beginning in about 1970, UNIX was developed by a group of programmers at Bell Labs (the research and development arm of AT&T.) The development of the new Operating System was initiated, at least partly, because a computer game ran too slowly on another computer with a different operating system. The small group of programmers, who did the original development, at first did so without any financial support from Bell Labs.
In other words, they did the development primarily for their own amusement.
Or course, eventually UNIX became a fully-supported product of AT&T with its own large staff of developers.
LINUX is a UNIX-like operating system that has been developed mainly by software developers working on the code in their own free time. According to the Wikipedia entry at http://en.wikipedia.org/wiki/LINUX, in 2001 a study of the most commonly used version of LINUX available at that time was performed. The study found that that particular version of the operating system contained 30 million lines-of-code (the most commonly used measure of the size of a computer program). By one measure this is equivalent to eight thousand man-years of development time, which can be equated to something like $1.08 Billion in monetary terms. In the years since 2001, both the number of lines-of-code and the number of man-hours invested in the project have grown considerably.
Think for a few moments about that - individuals working together to apply some eight thousand man-years of their professional skills in their own free time creating something with intellectual propery worth over a billion dollars! And, of course, those numbers have only gone up in the years since then.
Moreover, many claim that LINUX, particularly as a server operating system, is more robust and reliable than Microsoft Windows. This is clear evidence that the programmers who are freely contributing their time are very serious about what they are doing and are not compromising their professional efforts because they are not being paid for that time..
And the LINUX development is just a miunuscule part of the many hours that programmers spend on their “hobby” – which is the same as their profession.
There are probably other professions in which such a relationship between personal and professional interests exists. I have heard that some auto mechanics buy older card in disrepair and restore them in their spare time.
But such examples are surely the exception rather than the rule. At the other extreme, I’ve never heard of a ditch digger digging ditches as a hobby.
An important and related point is that there is a strong correlation between the skill of any particular programmer and the amount of time that programmer spends coding as a hobby. Really that only makes sense, of course. People tend to have hobbies involving things that they do well.
Implications:
Software developers tend not to mind working extra hours, as long as the work is challenging and they are convinced that the extra hours are important for the project. Because of their attachment to their families there are limits to the amount of extra work that they will do. It helps a great deal if they can work from home.
Furthermore, look for the programmers who have their own web site and who let you know that they write their own programs at home. Those are the programmers more likely to be your most enthusiastic software developers.
Programmers tend to have stable personal lives
It’s been said that the two best ways to get to know someone are to play poker with them or go on a business trip with them.
I’m not much of a poker player, but I have gone on business trips with many different people from many different professions: programmers, sales people, managers, even attorneys.
Overwhelmingly, the most boring people to travel with are the programmers. (Although I will admit that my somewhat limited experience traveling with attorneys would make them a possible contender for that title.) What’s wrong with traveling with programmers? They seem to always want to talk about their families. It’s sort of like the old cliché of visiting a family for dinner and ending up watching a slide show of their last vacation trip.
While I may not be impressed with the story of the programmer’s son who struck out the side in a Little League baseball game, I am impressed by the sincerity of the programmer’s enthusiasm for sharing that story.
Shortly after I graduated from college, I distinctly recall someone saying, “Engineers make good husbands”. (Note that this was at a time that 99% of all engineers were male.) In this era, you could also say that, “Programmers make good spouses” and be fundamentally correct.
Most programmers that I’ve worked with are married. Even those who are unmarried tend to be a bit boring – which can probably be interpreted as a sign of stability as well.
Implications:
This all means that they show up for work when needed. And they are also dependable in all of the other ways that professionalism is important.
I’m not much of a poker player, but I have gone on business trips with many different people from many different professions: programmers, sales people, managers, even attorneys.
Overwhelmingly, the most boring people to travel with are the programmers. (Although I will admit that my somewhat limited experience traveling with attorneys would make them a possible contender for that title.) What’s wrong with traveling with programmers? They seem to always want to talk about their families. It’s sort of like the old cliché of visiting a family for dinner and ending up watching a slide show of their last vacation trip.
While I may not be impressed with the story of the programmer’s son who struck out the side in a Little League baseball game, I am impressed by the sincerity of the programmer’s enthusiasm for sharing that story.
Shortly after I graduated from college, I distinctly recall someone saying, “Engineers make good husbands”. (Note that this was at a time that 99% of all engineers were male.) In this era, you could also say that, “Programmers make good spouses” and be fundamentally correct.
Most programmers that I’ve worked with are married. Even those who are unmarried tend to be a bit boring – which can probably be interpreted as a sign of stability as well.
Implications:
This all means that they show up for work when needed. And they are also dependable in all of the other ways that professionalism is important.
Subscribe to:
Comments (Atom)