So we all know (or are constantly reminded) that the simplest answer is usually correct. So when a client recently called to report that their project accounting accounts were missing (PA43001), we immediately started brainstorming "simple" explanations...
1. Maybe they aren't really "gone" (no, they really are gone)
2. Maybe somebody removed them (but how, I mean it's just the COGS accounts and they are simply gone)
3. Maybe someone working on another support case inadvertently removed them (not likely, as they were there at 2pm and gone at 4pm, and no cases were being worked in that time)
To be noted, the client is on GP2013 R2/YE 2014 (12.00.1801).
My coworkers sometimes give me a hard time because the last thing I tend to consider is an actual bug in the software. The reason I avoid this explanation is that it is too easy, and often is not the case. And particularly when data just disappears with no other process/issue/explanation, it doesn't seem likely that the software just decided to dump the data without provocation. So I like to make sure we exhaust other routes. So we went about fixing the issue in this case, restoring the accounts, but it was still bothersome that we could offer no explanation as to why it happened (again, racking my brain on a simple answer).
So we start a case, and found out that this is indeed a quality report (#9120 to be exact). An apparent bug in GP, that several clients have reported but Microsoft has been unable to replicate. Odd. Very odd. The good news being two-fold- first, of clients who have reported it, no one has had a second instance of it. And second, Microsoft GP support has a script you can run to create a shadow table that will track the project posting accounts table so you can monitor if something were to recur.
What's the lesson in this? The simplest explanation may just be that it is indeed a software bug. I guess that's it?
Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a director with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.
Monday, October 5, 2015
Friday, October 2, 2015
Finding batches with errors across all Dynamics GP company databases
By Steve Endow
A customer contacted me with an interesting problem. They utilize Post Master Enterprise to automatically post batches in over 150 company databases. The automatic batch posting is working fine, but they occasionally have some batches with errors that go into batch recovery. Post Master sends them an email message for each batch that goes into recovery, but with over 150 company databases, they wanted a way to generate a list of all problem batches across all of their company databases.
I haven't done a ton of research into batch recovery and how GP detects which batches to list in the batch recovery window, but based on a quick check of some failed batches in Fabrikam, it looks like the BCHSTTUS field in the SY00500 table was a good place to start.
This KB article lists the different values for the BCHSTTUS field.
https://support.microsoft.com/en-us/kb/852420
So now we can create a query like this:
SELECT * FROM TWO..SY00500 WHERE BCHSTTUS > 6
That's a start, but it isn't a great solution if we need to run the query in over 150 different databases.
So after some digging, I found this StackOverflow thread and used the last suggestion on the thread.
CREATE TABLE #tempgpquery
(
[DB] VARCHAR(50),
[Records] INT
)
DECLARE @db_name varchar(10)
DECLARE c_db_names CURSOR FOR
SELECT INTERID FROM DYNAMICS..SY01500
OPEN c_db_names
FETCH c_db_names INTO @db_name
WHILE @@Fetch_Status = 0
BEGIN
EXEC('
INSERT INTO #tempgpquery
SELECT ''' + @db_name + ''',COUNT(*) FROM ' + @db_name + '..SY00500 WHERE BCHSTTUS > 6
')
FETCH c_db_names INTO @db_name
END
CLOSE c_db_names
DEALLOCATE c_db_names
SELECT * FROM #tempgpquery
DROP TABLE #tempgpquery
It looks complex due to the temp table and cursor, but it's actually a fairly straightforward query.
You can modify the query to do whatever you need, and in this case it just does a count of records in SY00500 where the batch status is greater than 6 (the red text). I queried the list of valid company database names from the SY01500 table, and use that list in a cursor to loop through each database and query it.
It seems to work very well.
But like I said, I'm not 100% sure if the Batch Status field is the only indicator of batch recovery, so if anyone has more info on the query to properly detect batches that have gone to recovery, please let me know.
UPDATE: The very clever Tim Wappat took up the challenge to find a simpler and cleaner way to perform the query. He uses the novel approach of building a UNION ALL statement that is replicated through a join against sys.databases. The results are the same, but his query avoids the use of both the temp table and cursor. It is rather compact, which makes it a little more difficult to decipher, but it is pretty elegant. For his superior submission, Tim wins 100 Internet Points.
DECLARE @sql NVARCHAR(MAX);
SET @sql = N'DECLARE @cmd NVARCHAR(MAX); SET @cmd = N'''';';
SELECT @sql = @sql + N'SELECT @cmd = @cmd + N''UNION ALL
SELECT ''''' + QUOTENAME(name) + ''''', COUNT(*) FROM '
+ QUOTENAME(name) + '.dbo.SY00500 WHERE BCHSTTUS > 6 ''
WHERE EXISTS (SELECT 1 FROM ' + QUOTENAME(name)
+ '.sys.tables AS t
INNER JOIN ' + QUOTENAME(name) + '.sys.schemas AS s
ON t.[schema_id] = s.[schema_id]
WHERE t.name = N''SY00500''
AND s.name = N''dbo'');'
FROM sys.databases WHERE database_id > 4 AND state = 0;
SET @sql = @sql + N';
SET @cmd = STUFF(@cmd, 1, 10, '''');
PRINT @cmd;
EXEC sp_executesql @cmd;';
PRINT @sql;
EXEC sp_executesql @sql;
A customer contacted me with an interesting problem. They utilize Post Master Enterprise to automatically post batches in over 150 company databases. The automatic batch posting is working fine, but they occasionally have some batches with errors that go into batch recovery. Post Master sends them an email message for each batch that goes into recovery, but with over 150 company databases, they wanted a way to generate a list of all problem batches across all of their company databases.
I haven't done a ton of research into batch recovery and how GP detects which batches to list in the batch recovery window, but based on a quick check of some failed batches in Fabrikam, it looks like the BCHSTTUS field in the SY00500 table was a good place to start.
This KB article lists the different values for the BCHSTTUS field.
https://support.microsoft.com/en-us/kb/852420
So now we can create a query like this:
SELECT * FROM TWO..SY00500 WHERE BCHSTTUS > 6
That's a start, but it isn't a great solution if we need to run the query in over 150 different databases.
So after some digging, I found this StackOverflow thread and used the last suggestion on the thread.
CREATE TABLE #tempgpquery
(
[DB] VARCHAR(50),
[Records] INT
)
DECLARE @db_name varchar(10)
DECLARE c_db_names CURSOR FOR
SELECT INTERID FROM DYNAMICS..SY01500
OPEN c_db_names
FETCH c_db_names INTO @db_name
WHILE @@Fetch_Status = 0
BEGIN
EXEC('
INSERT INTO #tempgpquery
SELECT ''' + @db_name + ''',COUNT(*) FROM ' + @db_name + '..SY00500 WHERE BCHSTTUS > 6
')
FETCH c_db_names INTO @db_name
END
CLOSE c_db_names
DEALLOCATE c_db_names
SELECT * FROM #tempgpquery
DROP TABLE #tempgpquery
It looks complex due to the temp table and cursor, but it's actually a fairly straightforward query.
You can modify the query to do whatever you need, and in this case it just does a count of records in SY00500 where the batch status is greater than 6 (the red text). I queried the list of valid company database names from the SY01500 table, and use that list in a cursor to loop through each database and query it.
It seems to work very well.
But like I said, I'm not 100% sure if the Batch Status field is the only indicator of batch recovery, so if anyone has more info on the query to properly detect batches that have gone to recovery, please let me know.
UPDATE: The very clever Tim Wappat took up the challenge to find a simpler and cleaner way to perform the query. He uses the novel approach of building a UNION ALL statement that is replicated through a join against sys.databases. The results are the same, but his query avoids the use of both the temp table and cursor. It is rather compact, which makes it a little more difficult to decipher, but it is pretty elegant. For his superior submission, Tim wins 100 Internet Points.
DECLARE @sql NVARCHAR(MAX);
SET @sql = N'DECLARE @cmd NVARCHAR(MAX); SET @cmd = N'''';';
SELECT @sql = @sql + N'SELECT @cmd = @cmd + N''UNION ALL
SELECT ''''' + QUOTENAME(name) + ''''', COUNT(*) FROM '
+ QUOTENAME(name) + '.dbo.SY00500 WHERE BCHSTTUS > 6 ''
WHERE EXISTS (SELECT 1 FROM ' + QUOTENAME(name)
+ '.sys.tables AS t
INNER JOIN ' + QUOTENAME(name) + '.sys.schemas AS s
ON t.[schema_id] = s.[schema_id]
WHERE t.name = N''SY00500''
AND s.name = N''dbo'');'
FROM sys.databases WHERE database_id > 4 AND state = 0;
SET @sql = @sql + N';
SET @cmd = STUFF(@cmd, 1, 10, '''');
PRINT @cmd;
EXEC sp_executesql @cmd;';
PRINT @sql;
EXEC sp_executesql @sql;
Steve Endow is a Microsoft MVP for Dynamics GP and a Dynamics
GP Certified IT Professional in Los Angeles. He is the owner of Precipio
Services, which provides Dynamics GP integrations, customizations, and
automation solutions.
Tuesday, September 22, 2015
Project In One Company, Not All Companies
So, back in the day, Project Accounting had its own purchase order window. And we all moaned and complained about this. And we rejoiced when it was combined in to the standard purchase order window. But little did we appreciate the complexities that this would bring.
These complexities are illuminated when you try to use Project Accounting in one company but not all companies in your installation. This post focuses on the issues you will encounter in non-project accounting companies. Once Project Accounting is registered, you will begin receiving messages when accessing the Purchase Order Entry window, like 'Purchase Order Processing Setup Information is Missing or Damaged'. Ugh. And then, once you resolve that, every vendor you select when entering a purchase order will be greeted with 'Project Accounting information for this vendor does not exist. Do you want to add the vendor's project information?'. Double ugh. And keep in mind, these errors are encountered in companies where users DO NOT have access to the alternate project accounting windows.
On a side note, I am not exploring the Dynamics.Set file hack (having a separate non-Project Set file) in this post, as I generally am not a fan of separate Set files due to the potential for confusion and issues. But to each their own :)
So, what can you do...
For the first message related to Purchase Order Processing Setup, you will need to (at least temporarily) grant access to the alternate Purchase Order Processing Setup window for Project Accounting (Setup-System-Alternate/Modified Forms and Reports ID). Once you have access, go to Setup-Purchasing-Purchase Order Processing. Click the Project button, click OK, and close the Purchase Order Processing Setup window. At this point, even if you remove access to the alternate setup window, the first error messsage regarding setup information will be resolved.
But the vendor message will persist. And yes, as I mention above, you can have users simply say NO and continue on with the entry. But the pop up is indeed annoying. So you have a few options...
First, you have to address all existing vendors at the time of registration of project accounting. To do this, you can check out the script here that will do it automatically:
http://kbase.dyntools.com/home/project-accounting/project-accounting-information-for-this-vendor-does-not-exist)
Then, you need to decide how you want to handle new vendors added to GP. This is where the options come in to play.
Option A- Grant access to the alternate Vendor Maintenance window for Project Accounting. This would be the ONLY alternate project accounting window that the users will need to access. This way, when they save a new vendor, it will automatically save the project info as well (which will prevent the prompt to add project info when entering a purchase order for the vendor).
Option B- If Option A is not possible (for example, if you have another product that has an alternate Vendor Maintenance window as well that users need to access), then you can either schedule the script to create the project info to run every evening or look at some VBA code to populate the project info even when the alternate window is not used.
Please feel free to other options/workarounds you have found as well to avoid these headaches!
These complexities are illuminated when you try to use Project Accounting in one company but not all companies in your installation. This post focuses on the issues you will encounter in non-project accounting companies. Once Project Accounting is registered, you will begin receiving messages when accessing the Purchase Order Entry window, like 'Purchase Order Processing Setup Information is Missing or Damaged'. Ugh. And then, once you resolve that, every vendor you select when entering a purchase order will be greeted with 'Project Accounting information for this vendor does not exist. Do you want to add the vendor's project information?'. Double ugh. And keep in mind, these errors are encountered in companies where users DO NOT have access to the alternate project accounting windows.
On a side note, I am not exploring the Dynamics.Set file hack (having a separate non-Project Set file) in this post, as I generally am not a fan of separate Set files due to the potential for confusion and issues. But to each their own :)
So, what can you do...
For the first message related to Purchase Order Processing Setup, you will need to (at least temporarily) grant access to the alternate Purchase Order Processing Setup window for Project Accounting (Setup-System-Alternate/Modified Forms and Reports ID). Once you have access, go to Setup-Purchasing-Purchase Order Processing. Click the Project button, click OK, and close the Purchase Order Processing Setup window. At this point, even if you remove access to the alternate setup window, the first error messsage regarding setup information will be resolved.
But the vendor message will persist. And yes, as I mention above, you can have users simply say NO and continue on with the entry. But the pop up is indeed annoying. So you have a few options...
First, you have to address all existing vendors at the time of registration of project accounting. To do this, you can check out the script here that will do it automatically:
http://kbase.dyntools.com/home/project-accounting/project-accounting-information-for-this-vendor-does-not-exist)
Then, you need to decide how you want to handle new vendors added to GP. This is where the options come in to play.
Option A- Grant access to the alternate Vendor Maintenance window for Project Accounting. This would be the ONLY alternate project accounting window that the users will need to access. This way, when they save a new vendor, it will automatically save the project info as well (which will prevent the prompt to add project info when entering a purchase order for the vendor).
Option B- If Option A is not possible (for example, if you have another product that has an alternate Vendor Maintenance window as well that users need to access), then you can either schedule the script to create the project info to run every evening or look at some VBA code to populate the project info even when the alternate window is not used.
Please feel free to other options/workarounds you have found as well to avoid these headaches!
Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a director with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.
Tuesday, September 15, 2015
Microsoft Dynamics GP 2016 should go meatless
By Steve Endow
Roving Dynamics GP reporter Tim Wappat travelled to London today to get a sneak peek at a very early version of Dynamics GP 2016. He posted an article on his blog:
http://www.timwappat.info/post/2015/09/15/GP2016-looking-sweet-in-HTML5
One of the interesting side notes that he mentions is that the "hamburger icon", or "hamburger menu" was being used, for the time being, in the pre-release GP 2016 web client.
The demo that Tim saw was obviously pre-pre-pre-Release, and everything is subject to change, but if Microsoft is even considering using the hamburger menu, I beseech them to reconsider.
I admit that I didn't know the name of that three-bar icon until a few weeks ago--which is when I read this very convincing article on why the hamburger menu is a horrible UI element.
http://deep.design/the-hamburger-menu/ (link dead as of July 2017)
The article is very convincing in its explanation of why the hamburger menu is detrimental to application navigation, and then it goes on to cite numerous examples and statistics to support its assertion.
Here is another article with the same conclusion and more stats:
https://redbooth.com/blog/hamburger-menu-iphone-app
Update:
Another article:
https://speckyboy.com/analyzing-effectiveness-hamburger-menus-web-design/
And another:
https://www.nngroup.com/articles/hamburger-menus/
And another:
http://jamesarcher.me/hamburger-menu
And yet another:
https://lmjabreu.com/post/why-and-how-to-avoid-hamburger-menus/
Are you seeing a trend here?
After reading about the design deficiencies, I now notice how annoying the hamburger menu is on my iPhone apps--I am looking for settings and options and features, but can't find them--until I realize there is an innocuous little three line icon in the corner that I have to click to expand a menu. It's a great way to hide features so that your users never use them.
While there may be some situations where limited use of the hamburger menu may make sense--rarely used settings or infrequently used windows, it definitely should be used very sparingly. But based on the articles above, it should be replaced with some other menu design.
Save the cows. Get rid of the hamburger.
Roving Dynamics GP reporter Tim Wappat travelled to London today to get a sneak peek at a very early version of Dynamics GP 2016. He posted an article on his blog:
http://www.timwappat.info/post/2015/09/15/GP2016-looking-sweet-in-HTML5
One of the interesting side notes that he mentions is that the "hamburger icon", or "hamburger menu" was being used, for the time being, in the pre-release GP 2016 web client.
The demo that Tim saw was obviously pre-pre-pre-Release, and everything is subject to change, but if Microsoft is even considering using the hamburger menu, I beseech them to reconsider.
I admit that I didn't know the name of that three-bar icon until a few weeks ago--which is when I read this very convincing article on why the hamburger menu is a horrible UI element.
http://deep.design/the-hamburger-menu/ (link dead as of July 2017)
The article is very convincing in its explanation of why the hamburger menu is detrimental to application navigation, and then it goes on to cite numerous examples and statistics to support its assertion.
Here is another article with the same conclusion and more stats:
https://redbooth.com/blog/hamburger-menu-iphone-app
Update:
Another article:
https://speckyboy.com/analyzing-effectiveness-hamburger-menus-web-design/
And another:
https://www.nngroup.com/articles/hamburger-menus/
And another:
http://jamesarcher.me/hamburger-menu
And yet another:
https://lmjabreu.com/post/why-and-how-to-avoid-hamburger-menus/
Are you seeing a trend here?
After reading about the design deficiencies, I now notice how annoying the hamburger menu is on my iPhone apps--I am looking for settings and options and features, but can't find them--until I realize there is an innocuous little three line icon in the corner that I have to click to expand a menu. It's a great way to hide features so that your users never use them.
While there may be some situations where limited use of the hamburger menu may make sense--rarely used settings or infrequently used windows, it definitely should be used very sparingly. But based on the articles above, it should be replaced with some other menu design.
Save the cows. Get rid of the hamburger.
Steve Endow is a Microsoft MVP for Dynamics GP and a Dynamics
GP Certified IT Professional in Los Angeles. He is the owner of Precipio
Services, which provides Dynamics GP integrations, customizations, and
automation solutions.
Turn off all Dynamics GP posting reports in the Fabrikam test company
By Steve Endow
Update: Victoria Yudin correctly noted that there are times when posting reports are helpful or required, perhaps for training or identifying errors. Absolutely--posting reports are definitely necessary in certain situations, even in Fabrikam. I chose to turn off the posting reports in my test company because I am constantly doing repetitive testing of batch posting for my projects. I know that my data is fine, the transactions are fine, and everything posts fine, so in my situation, I don't need the posting reports or the report dialogs, and I turn everything off to avoid having to click Cancel constantly.
It's pretty sad when you know how many times you have to click the cancel button on the report dialog boxes after you post a certain Dynamics GP batch.
Finally, my laziness wanting to avoid constantly clicking a Cancel button finally overtook my laziness to disable all posting reports, and I finally spent 10 seconds to create the script to turn off all posting reports in Fabrikam.
There. Done.
I now need to make it a standard part of the GP installation process after I create the Fabrikam company.
Batches and posting reports...two anachronisms of the ERP world that GP will probably never abandon...
Ask a NetSuite consultant about their "batches" and "posting reports" if you want to see some puzzled reactions.
Update: Victoria Yudin correctly noted that there are times when posting reports are helpful or required, perhaps for training or identifying errors. Absolutely--posting reports are definitely necessary in certain situations, even in Fabrikam. I chose to turn off the posting reports in my test company because I am constantly doing repetitive testing of batch posting for my projects. I know that my data is fine, the transactions are fine, and everything posts fine, so in my situation, I don't need the posting reports or the report dialogs, and I turn everything off to avoid having to click Cancel constantly.
It's pretty sad when you know how many times you have to click the cancel button on the report dialog boxes after you post a certain Dynamics GP batch.
Finally, my laziness wanting to avoid constantly clicking a Cancel button finally overtook my laziness to disable all posting reports, and I finally spent 10 seconds to create the script to turn off all posting reports in Fabrikam.
UPDATE TWO..SY02200 SET PRNTJRNL = 0
There. Done.
I now need to make it a standard part of the GP installation process after I create the Fabrikam company.
Batches and posting reports...two anachronisms of the ERP world that GP will probably never abandon...
Ask a NetSuite consultant about their "batches" and "posting reports" if you want to see some puzzled reactions.
Steve Endow is a Microsoft MVP for Dynamics GP and a Dynamics
GP Certified IT Professional in Los Angeles. He is the owner of Precipio
Services, which provides Dynamics GP integrations, customizations, and
automation solutions.
eConnect error: hexadecimal value 0x00, is an invalid character
By Steve Endow
A client emailed me regarding the following error they were receiving with a Dynamics GP 2010 eConnect SOP Invoice integration.
eConnectException: '.', hexadecimal value 0x00, is an invalid character. Line 5, position -248.
Based on the error message, it appeared that there was some type of invalid character in the CSV source data file. But when we looked at the CSV file in a text editor, everything looked fine.
So I ran the integration in debug mode in Visual Studio, and when the eConnect insert failed, I checked the XML data that was submitted. The results were interesting.
Trans Number: 205112482
Borrower: THOMAS JEFFERSON
VIRGINIA COLONIES
Title Company: & #x0 ;
Commitment Number: & #x0 ;
File Name: & #x0 ;
Lien Type: FIRST
Loan Type: CONVENTIONAL
(I've had to add spaces to the hex string so that Blogger doesn't strip them out)
The text above is a long comment string that is being inserted with the SOP invoice header. It seems that there is an odd hex character in three of the field values.
I had to look up that hex character, and learned that it is the hex value of the null character. Apparently eConnect is not a fan of the null character, so that is causing the error.
This is all that I see when I open the file in UltraEdit and view in text mode. Looks fine.
But if I view the file in the UltraEdit HEX mode, I see this.
Notice the "00" values in the data on the left, and the period in the representation on the right. That's our problem.
So how do we deal with these rogue null characters? Ideally, the source data file would be corrected so that they are not inserted in the file in the first place. But in case they do show up in the data file again, it's fairly easy to remove them using Regular Expressions.
So I added this simple function to strip the null character from the field value.
Once I applied the RemoveNull function to the invoice comment text, the invoices imported fine and the error went away.
I've never encountered the "null" character before, but fortunately it was a pretty easy fix.
A client emailed me regarding the following error they were receiving with a Dynamics GP 2010 eConnect SOP Invoice integration.
eConnectException: '.', hexadecimal value 0x00, is an invalid character. Line 5, position -248.
Based on the error message, it appeared that there was some type of invalid character in the CSV source data file. But when we looked at the CSV file in a text editor, everything looked fine.
So I ran the integration in debug mode in Visual Studio, and when the eConnect insert failed, I checked the XML data that was submitted. The results were interesting.
Trans Number: 205112482
Borrower: THOMAS JEFFERSON
VIRGINIA COLONIES
Title Company: & #x0 ;
Commitment Number: & #x0 ;
File Name: & #x0 ;
Lien Type: FIRST
Loan Type: CONVENTIONAL
(I've had to add spaces to the hex string so that Blogger doesn't strip them out)
The text above is a long comment string that is being inserted with the SOP invoice header. It seems that there is an odd hex character in three of the field values.
I had to look up that hex character, and learned that it is the hex value of the null character. Apparently eConnect is not a fan of the null character, so that is causing the error.
This is all that I see when I open the file in UltraEdit and view in text mode. Looks fine.
But if I view the file in the UltraEdit HEX mode, I see this.
Notice the "00" values in the data on the left, and the period in the representation on the right. That's our problem.
So how do we deal with these rogue null characters? Ideally, the source data file would be corrected so that they are not inserted in the file in the first place. But in case they do show up in the data file again, it's fairly easy to remove them using Regular Expressions.
So I added this simple function to strip the null character from the field value.
public static
string RemoveNull(string
input, string replaceWith)
{
string output = Regex.Replace(input,
"\x00", replaceWith);
return output;
}
Once I applied the RemoveNull function to the invoice comment text, the invoices imported fine and the error went away.
I've never encountered the "null" character before, but fortunately it was a pretty easy fix.
Steve Endow is a Microsoft MVP for Dynamics GP and a Dynamics
GP Certified IT Professional in Los Angeles. He is the owner of Precipio
Services, which provides Dynamics GP integrations, customizations, and
automation solutions.
Monday, September 14, 2015
Design Specifications- What, How, Yet, How Much?
I know we have all been there. You (or your team member) create a fabulous
customization, report, or interface. Or,
at least you think it’s fabulous. But
once it’s delivered to the client, the issues begin…
- - It doesn’t work the way it we thought it would
- - We need this additional work for it to meet our needs
- - We thought we already explained this
And the list goes on and on and on. I had a webinar last week for GPUG about
creating specifications for customizations, reports, and interfaces, and I
thought I would share some of that content here as well. I continually am reminded of the importance
of the spec process, it seems like every week.
And if I let it slide, either because I think it’s not a big deal or the
client is resistant to committing to a spec document for whatever reason, the
universe almost always course corrects me at some point in the project (e.g.,
budget overrun, client dissatisfaction, etc).
So we all know the reasons to create specs, right?
- - Reduce risk
- - Ensure clear communication and expectations
- - Accurately scope work
- - Create a better outcome in terms of design and client response
But what are the key components of a successful spec? Now, I completely understand that this list
will vary based on the client, the developer, and the specifics of the
customization/report/interface being addressed.
This list simply serves as a starting point checklist of the normal
“must-haves”:
- - WHAT is the spec for? A functional/plain language description of the problem to be solved. Visual flowcharts/mockups as necessary to make the point. Include any caveats/assumptions/risks to be clear up front.
- - HOW do you plan to address the need? The technologies/tools/methods to be used, including prerequisites for deployment. At a minimum a high level technical design, but could be more detailed including fields, calculations, and needed logic. Whether it is high-level or detailed depends on what you need to be able to accurately scope it out, and how involved the project may be. If it is a large project, the initial spec may have a high level technical design with a statement that a full technical design is included in the estimate and may change. On smaller projects, a full technical design may not take much time and allow you to better scope/estimate the project.
- - YET, what might be the hurdles? Always note any exceptions, assumptions, or outstanding questions that might impact the estimate and/or complexity of the project. It’s okay to have outstanding items, as long as they are documented and ultimately addressed in the project.
- - HOW MUCH will this cost? And don’t just focus on development costs, make sure you include project management, design, testing (unit, function, process, and supporting end user acceptance testing) in your estimate.
I love getting all of this down on paper, I just do. And it is great when a client fully commits
to the process, and we can make sure we are all on the same page before work
starts. But, as with anything in this
line of work, you can’t make the perfect the enemy of the adequate at
times. So although a spec is important,
don’t let it become the bat with which you bully others (either your team
members or the client). Try to remember
the intention of the spec, and approach it with good faith. Things may change as the project proceeds,
and the client may grow in their understanding of their own needs. Of course, assess the impact of these changes
on your budget and timeline, but also know that a minor change with no
measurable impact can be addressed without a lot of hub-bub (assuming that the
necessary decision makers are aware).
Naturally, everything above is just my opinion. I would love to hear from you all regarding
your “must-have’s” for successful spec documents, and your challenges (and
successes) with applying these guidelines to projects.
Christina Phillips is a Microsoft Certified Trainer and Dynamics GP Certified Professional. She is a director with BKD Technologies, providing training, support, and project management services to new and existing Microsoft Dynamics customers. This blog represents her views only, not those of her employer.
Subscribe to:
Posts (Atom)