Estimating the cost of custom software development is difficult. I've tried to think of ways to make it more accurate and reliable, but unfortunately so far I haven't found anything better than the "30% Rule".
Many years ago I had the privilege of working with a veteran software developer named Jim Walters. Jim probably had over 25 years of experience by that time, and had years of experience developing complex, global software applications. As he and I began to work on a new project, a custom medical clinic scheduling and patient management system, we documented the requirements and then worked on an estimate for the project.
The scope was pretty significant, and the hours were correspondingly large. When we finally filled in the all of tasks that we could think of and put hours next to them, Jim added up the total hours in Excel. He then added a formula below the total where he multiplied the hours by 1.3, which he declared was the realistic estimate for the project.
When I asked him about the 30% factor, he said that over the course of many years and many projects, he and colleagues had analyzed their estimates and their actual hours to complete projects, and overall, they came to a conclusion: Despite their best efforts to estimate complex software development projects accurately, they typically ended up requiring roughly 30% more time than they estimated. 30% seems like a lot though, doesn't it? And adding a 30% margin on top of an estimate could give the impression that you don't know what you are doing--either you can't code "efficiently", or you can't estimate.
He explained that custom software development is complex. It is difficult to anticipate and gather every requirement before the project starts. Sometimes business users don't even know that some things are requirements. And sometimes business users change their minds. And nearly every complex software project runs into at least one form of technical issue, whether it is a bug, and incompatibility, or simply something that you haven't coded or used before, and therefore have to figure out and learn. It's complex and by definition, you've never coded this custom software before, and therefore you can't possibly anticipate everything in advance and bake it into an estimate.
So, we used his 30% rule to produce an estimate for the project, which we then presented to management for approval. After the project was completed and delivered, I reviewed the budget to actual, and sure enough, we came in at 128% of our original estimate.
Despite the apparent wisdom of the 30% rule, I've struggled to use it in most of my GP projects. One challenge is simply remembering to add the 1.3 factor--if a project is something I've done before, I sometimes forget the potential risks, and therefore forget to factor those unknown risks into my estimate.
More commonly, it has been very difficult to "sell" this factor to most people, even if they don't know that I'm using it. By presenting a realistic estimate that reflects the likely total cost of the project, you run the risk of giving people sticker shock. Salespeople want to sell the solution at a "competitive" price, which is almost always lower than your estimate. And then there are clients who see the total hours and assess that the estimate is "too high", or simply too expensive for them, killing the project. And if you are bidding against a firm that can't estimate accurately, does not provide a realistic estimate, or simply underbids, your estimate will look much too high, even if it is accurate, thereby damaging your credibility and trust with the client.
Even if these challenges make it difficult to use the 30% rule for estimates that are presented to management or clients, I still think it is a good practice to keep the 1.3 number in mind, and make certain preparations in case you do exceed your original (non 1.3x) estimate. It would allow you to be more cognizant of scope changes, the need for change requests, and the need for budget discussions during the project, rather than waiting until you are over budget to have those conversations.
If anyone has any other good suggestions for estimating custom development, I'm all ears!
Monday, March 30, 2009
Thursday, March 26, 2009
Upgrade Issue with Project Accounting and Purchase Order
This week I had an interesting issue pop up after an upgrade from GP9 to GP10. We have done many upgrades at this point, including ones involving project accounting, so this issue was a surprise and makes me wonder what caused it.
There were no errors during the upgrade, but post upgrade a user noticed that there were no longer any account numbers on purchase order line items. When she went to receive the purchase orders, the receipts did not default a Cost of Goods Sold account since there was no account on the line item on the purchase order. All of their purchase orders are project purchase orders, with projects and cost categories on the line items.
I looked in the database, and sure enough, in the POP10110 there were no values for the INVINDX field which stores the account index for PO lines. None. Zero. Zilch. Nada. For 7500 lines. To make sure I was not going crazy, I manually entered a purchase order and sure enough, the INVINDX populated fine. So then, to make sure it was an upgrade issue, I restored a backup from GP9 (when I knew POs and receipts were functioning, and accounts were defaulting). And in GP9, the INVINDX was blank as well.
So...I started to wonder if perhaps this was somehow related to the feature pack and changes made to the line item functionality with regards to accounts in purchase order. I still do not know for sure, but it seems like a likely reason (feel free to share if you know, or can disqualify this theory).
But I still needed to fix the issue, so I looked in the PA10601, the PA Purchase Order Line table. And the PACogs_Idx field was still populated. I checked my test purchase order that I had entered, to make sure that it populated both POP10110.INVINDX and PA10601.PACogs_Idx with the same values to make sure I was not making a bad assumption. Then it was easy enough to do a join on the PO number and ORD fields in order to update the POP10110 with the correct account index.
All is well now, and the user is able to enter and post (with accounts defaulting). Anyone else come across this?
There were no errors during the upgrade, but post upgrade a user noticed that there were no longer any account numbers on purchase order line items. When she went to receive the purchase orders, the receipts did not default a Cost of Goods Sold account since there was no account on the line item on the purchase order. All of their purchase orders are project purchase orders, with projects and cost categories on the line items.
I looked in the database, and sure enough, in the POP10110 there were no values for the INVINDX field which stores the account index for PO lines. None. Zero. Zilch. Nada. For 7500 lines. To make sure I was not going crazy, I manually entered a purchase order and sure enough, the INVINDX populated fine. So then, to make sure it was an upgrade issue, I restored a backup from GP9 (when I knew POs and receipts were functioning, and accounts were defaulting). And in GP9, the INVINDX was blank as well.
So...I started to wonder if perhaps this was somehow related to the feature pack and changes made to the line item functionality with regards to accounts in purchase order. I still do not know for sure, but it seems like a likely reason (feel free to share if you know, or can disqualify this theory).
But I still needed to fix the issue, so I looked in the PA10601, the PA Purchase Order Line table. And the PACogs_Idx field was still populated. I checked my test purchase order that I had entered, to make sure that it populated both POP10110.INVINDX and PA10601.PACogs_Idx with the same values to make sure I was not making a bad assumption. Then it was easy enough to do a join on the PO number and ORD fields in order to update the POP10110 with the correct account index.
All is well now, and the user is able to enter and post (with accounts defaulting). Anyone else come across this?
Project Accounting Cost Allocation By Unit
Okay, so this is what happens when I am stranded in a hotel room in Denver during a blizzard, I gnaw on something until I manage to understand what it is doing.
Since the feature pack came out last summer, I have been aware of the Project Allocation feature but have not had cause to use it. I had played around with it some, but really did not understand the capabilities relative to the Unit allocation method at the Cost Category basis. So, tonight I did some testing and I think I have it figured out (at least partially).
From what I can tell, both fields deal with timesheet cost categories. So, let's assume that I accumulate vacation time in an overhead project and I want to allocate the hours (and cost) to other projects based on their billable time (assuming that the more billable time there is, the more vacation there would be as well).
Considering this all came from testing (the documentation I could find was not particularly clear), please feel free to post comments, clarifications, and corrections :)
So, let's assume that I have the following setup:
Since the feature pack came out last summer, I have been aware of the Project Allocation feature but have not had cause to use it. I had played around with it some, but really did not understand the capabilities relative to the Unit allocation method at the Cost Category basis. So, tonight I did some testing and I think I have it figured out (at least partially).
From what I can tell, both fields deal with timesheet cost categories. So, let's assume that I accumulate vacation time in an overhead project and I want to allocate the hours (and cost) to other projects based on their billable time (assuming that the more billable time there is, the more vacation there would be as well).
Considering this all came from testing (the documentation I could find was not particularly clear), please feel free to post comments, clarifications, and corrections :)
So, let's assume that I have the following setup:
- VAC is my vacation cost category for timesheets
- BILL is my billable cost category for timesheets
- MISC is my cost category for miscellaneous logs
- ALLOC is my miscellaneous ID
- OHPROJECT is my overhead project
- PROJECTA is one billable project
- PROJECTB is another billable project
I have posted timesheet transactions that result in the following actuals on the projects:
- OHPROJECT: 100 hours VAC for a total of $10000 in cost
- PROJECTA: 20 hrs BILL for a total of $2000 in cost
- PROJECTB: 30 hrs BILL for a total of $3000 in cost
I can set up my project allocations as follows:
From:
- Project: OHPROJECT
- Cost Category: VAC
- Misc ID: ALLOC
- Misc Log Cost Category: MISC
To:
- Project: PROJECTA
- Misc ID: ALLOC
- Misc Log Cost Category: MISC
- Cost Category Basis: BILL
Method: Unit
Then enter a second line with the following allocation...
From:
Project: OHPROJECT
Cost Category: VAC
Misc ID: ALLOC
Misc Log Cost Category: MISC
To:
Project: PROJECTB
Misc ID: ALLOC
Misc Log Cost Category: MISC
Cost Category Basis: BILL
Method: Unit
This allocation setup will result in the following allocations being created by taking the cost category basis and determining the portion of the whole. For example, the total quantity for the cost category basis for PROJECTA and PROJECTB is 50 hrs. So PROJECTA will get 40% of the allocation (20/50) and PROJECTB will get 60% of the allocation (30/50). As Mike Lupro pointed out, this will allocate the full amount in VAC on OHPROJECT to PROJECTA and PROJECT B.:
- Allocated to PROJECTA: $4000
- Allocated to PROJECTB: $6000
Well, there you go! Pretty nifty I think, and I could definitely see applying this in the future. Let me know what you think.
Saturday, March 14, 2009
Remote Desktop Nirvana (Updated)
Every once in a while, I stumble across some feature, option, utility, or application that simultaneously makes me say "Wow! That's amazing!", and "D'oh! I should have known about that!". These are great features / options / utilities / apps that are no secret, but aren't necessarily well publicized.
I received an e-mail at 9:30pm this Saturday evening from a client who suddenly started getting errors from a GP related SQL Server job. We started a GoToMeeting session to look at the SQL Server issue, and as soon as I saw his desktop I noticed something out of the ordinary. He said "We're looking at Server A now, but if you want to look at Server B, just click it in the list on the left."
This is what I saw:
Never having seen this before, I asked him if this was some type of 3rd party server management app that he uses--perhaps like a VNC or Citrix management console of some kind, something I have seen at other clients. "No, it's just part of the Server 2003 Admin Pack."
Sure enough, this is a fantastic utility included in the free Windows Server 2003 Administration Tools Pack. The tools pack includes several tools, but the one I was most interested in is the "Remote Desktops" MMC snap-in.
The Tools can be downloaded here. Just make sure to download the SP1 version, as the original version, which is still available for download, does not allow you to connect to a Terminal Server running on a port other than 3389. After installation, the Remote Desktops app should appear under your Administrative Tools program group.
This MMC snap-in allows you to save multiple RDP profiles in a single place, avoiding the need for multiple RDP files ( I currently have 13 of them sitting on my desktop) or hunting through the MRU (most recently used) list on the Remote Desktop Connection app window. Once you setup the server connections, with just a single click on a server name on the left, you can quickly login to a server and also switch from one RDP session to another.
It doesn't offer all of the connection options of the Terminal Services Client, but I generally don't need the extra options:
And something that I find very valuable: It allows you to have an RDP session that will automatically fill the MMC window, regardless of size or aspect ratio. You can choose to fill the MMC window, choose a standard desktop size, or even specify a custom resolution.
So I'm no longer limited to the standard 1024, 1280, or full screen options. (That is actually the only feature I appreciated in Virtual PC vs. virtual server--the ability to dynamically resize the VPC window.) I like the size and convenience of the Terminal Server Client full screen mode, but it's a hassle when I need to minimize or move the RDP window out of the way, or when I have to work with multiple sessions in full screen mode.
The Remote Desktops app effectively let's me have several simultaneous near-full-screen sessions in a single desktop app. Very handy when jumping between different servers throughout the day.
If you are only working in a single RDP connection at a time, the standard MS TSC app in full screen mode is great, as it gives you ALT+Tab, the Windows key, and other shortcuts that aren't available otherwise. But if you have to bounce between multiple servers, the Remote Desktops utility is much more convenient.
Because it is an MMC snap-in, it does have the standard MMC navigation and UI quirks, but given what it offers, it's a great solution.
UPDATE: Reader Jivtesh brought up an excellent point: What about this feature in Server 2008? He informed me that it is a standard feature in Windows Server 2008, but after looking for it, I didn't see an icon for it under Administrative Tools.
It appears that it may not have an icon by default in Server 2008, but it is present by default, and is very easy to get working.
Here is the KB article with instructions.
To open Remote Desktops from the MMC
You can then do File --> Save As to save an MSC file that you can launch to open Remote Desktops.
I received an e-mail at 9:30pm this Saturday evening from a client who suddenly started getting errors from a GP related SQL Server job. We started a GoToMeeting session to look at the SQL Server issue, and as soon as I saw his desktop I noticed something out of the ordinary. He said "We're looking at Server A now, but if you want to look at Server B, just click it in the list on the left."
This is what I saw:
Never having seen this before, I asked him if this was some type of 3rd party server management app that he uses--perhaps like a VNC or Citrix management console of some kind, something I have seen at other clients. "No, it's just part of the Server 2003 Admin Pack."
Sure enough, this is a fantastic utility included in the free Windows Server 2003 Administration Tools Pack. The tools pack includes several tools, but the one I was most interested in is the "Remote Desktops" MMC snap-in.
The Tools can be downloaded here. Just make sure to download the SP1 version, as the original version, which is still available for download, does not allow you to connect to a Terminal Server running on a port other than 3389. After installation, the Remote Desktops app should appear under your Administrative Tools program group.
This MMC snap-in allows you to save multiple RDP profiles in a single place, avoiding the need for multiple RDP files ( I currently have 13 of them sitting on my desktop) or hunting through the MRU (most recently used) list on the Remote Desktop Connection app window. Once you setup the server connections, with just a single click on a server name on the left, you can quickly login to a server and also switch from one RDP session to another.
It doesn't offer all of the connection options of the Terminal Services Client, but I generally don't need the extra options:
And something that I find very valuable: It allows you to have an RDP session that will automatically fill the MMC window, regardless of size or aspect ratio. You can choose to fill the MMC window, choose a standard desktop size, or even specify a custom resolution.
So I'm no longer limited to the standard 1024, 1280, or full screen options. (That is actually the only feature I appreciated in Virtual PC vs. virtual server--the ability to dynamically resize the VPC window.) I like the size and convenience of the Terminal Server Client full screen mode, but it's a hassle when I need to minimize or move the RDP window out of the way, or when I have to work with multiple sessions in full screen mode.
The Remote Desktops app effectively let's me have several simultaneous near-full-screen sessions in a single desktop app. Very handy when jumping between different servers throughout the day.
If you are only working in a single RDP connection at a time, the standard MS TSC app in full screen mode is great, as it gives you ALT+Tab, the Windows key, and other shortcuts that aren't available otherwise. But if you have to bounce between multiple servers, the Remote Desktops utility is much more convenient.
Because it is an MMC snap-in, it does have the standard MMC navigation and UI quirks, but given what it offers, it's a great solution.
UPDATE: Reader Jivtesh brought up an excellent point: What about this feature in Server 2008? He informed me that it is a standard feature in Windows Server 2008, but after looking for it, I didn't see an icon for it under Administrative Tools.
It appears that it may not have an icon by default in Server 2008, but it is present by default, and is very easy to get working.
Here is the KB article with instructions.
To open Remote Desktops from the MMC
Click Start, click Run, type mmc in the Open box, and then click OK.
On the File menu, click Add/Remove Snap-in.
In the Available snap-ins list, click Remote Desktops, and then click Add.
Click OK.
You can then do File --> Save As to save an MSC file that you can launch to open Remote Desktops.
Wednesday, March 4, 2009
Installing GP 10 on Windows Server 2008 (and Vista)
Today, for the first time, I finally had to install GP 10 on Windows Server 2008. The server also has SQL Server 2008, which I'm embarrassed to say I just installed for the first time this week.
The server installed fine, and SQL 2008 installed fine, and GP appeared to install fine. But when I launched GP Utilities, I got this error:
"An error occurred while using the BCP utility--data was not correctly copied to the server."
At first I thought it might be that I didn't install BCP during the SQL 2008 installation. Having never installed SQL 2008 before, and seeing that there was a SQL 2008 feature pack with a separate release of SQL 2008 Command Line utilities, I thought that maybe BCP is no longer distributed in the standard SQL 2008 release.
Of course installing the command line utilities didn't help, so I checked the PartnerSource Knowledge Base, which offered nothing useful.
I then fell back to my good buddy Google, which pointed me straight to Mohammad Daoud's blog entry with the solution to the issue (Run GP Utilities as Administrator).
It's apparently the same issue that occurs on Vista with GP, but as I have avoided Vista like the plague, I've been lucky enough to never experience that issue.
Thanks fellow GP bloggers!
Update: After reading more blog posts, apparently installing GP outside of the Program Files directory on Vista and Windows 2008 will allow you to avoid the UAC issue entirely.
The server installed fine, and SQL 2008 installed fine, and GP appeared to install fine. But when I launched GP Utilities, I got this error:
"An error occurred while using the BCP utility--data was not correctly copied to the server."
At first I thought it might be that I didn't install BCP during the SQL 2008 installation. Having never installed SQL 2008 before, and seeing that there was a SQL 2008 feature pack with a separate release of SQL 2008 Command Line utilities, I thought that maybe BCP is no longer distributed in the standard SQL 2008 release.
Of course installing the command line utilities didn't help, so I checked the PartnerSource Knowledge Base, which offered nothing useful.
I then fell back to my good buddy Google, which pointed me straight to Mohammad Daoud's blog entry with the solution to the issue (Run GP Utilities as Administrator).
It's apparently the same issue that occurs on Vista with GP, but as I have avoided Vista like the plague, I've been lucky enough to never experience that issue.
Thanks fellow GP bloggers!
Update: After reading more blog posts, apparently installing GP outside of the Program Files directory on Vista and Windows 2008 will allow you to avoid the UAC issue entirely.
Monday, March 2, 2009
New Orleans or Bust!
I am one of those people who gets giddy at the prospect of spending a week at a conference, especially a Dynamics-centered one like Convergence. I am a bit of a learning-junkie, and love to have the opportunity to absorb and share as much information as I can with others. And Convergence is such a great opportunity to meet up with customers, past students, other consultant-friends, as well as the MS folks in a fun environment. So, I look forward to heading down south this weekend for a week of learning and catching up with everyone.
I'll be working in the labs in the community and learning center as a technical learning guide. I would love to meet up with fellow Dynamics bloggers and any followers we might have, so please stop by and do a lab or two and say hello! I know I personally have learned so much from following the other Dynamics bloggers out there and can't wait to put faces to names!
See you in NOLA!
Christina Phillips
I'll be working in the labs in the community and learning center as a technical learning guide. I would love to meet up with fellow Dynamics bloggers and any followers we might have, so please stop by and do a lab or two and say hello! I know I personally have learned so much from following the other Dynamics bloggers out there and can't wait to put faces to names!
See you in NOLA!
Christina Phillips
Subscribe to:
Posts (Atom)