My dear Loyal Visitor,

Let me get to the point: this blog is moving to the new domain:

http://www.NavigateIntoSuccess.com/

I believe it deserved it.

This blog has started as a hobby a year and a half ago. It took it six months before a first visitor arrived to it, and about nine months before it really kicked-off.

Today, there are about 160 daily web visitors, 70 subscribers to my Feedburner feed, and 60 subscribers to WordPress feed – all in all there are almost 300 hundred people reading this stuff every day.

For a narrow-niche blog, such as this, I believe I do fairly well.

What does the move to the new domain mean for you, and for this blog:

1. My blog will get a more wide-angle perspective: I’ll definitely extend it to cover not only NAV, but ERP in general, as well as general Project Management best practices.
2. You will still be able to read about Sure Step – I’ll continue to actively promote and evangelize it. I believe in it!
3. The new blog will bring more interactivity: possibility to Digg posts straight from there, there will be polls from time to time, I believe it will deliver more fun.
4. I’ll try building a community out of this blog, get in touch with you, get us all share our opinions, experiences, ideas on how to get the most value out of NAV and ERP implementations.
5. No more posts here – new content will get posted exclusively at http://www.NavigateIntoSuccess.com/
6. No more comments on posts on this blog.
7. A lot of fun!

Thank you for staying with me, for reading my blog, for your time and attention—it was an honor having you here. I look forward to seeing you at http://www.NavigateIntoSuccess.com/!

Yours truly,

Vjeko

Read this post at this blog’s new URL: NavigateIntoSuccess.com.

Where I have been for the past eight months…

This blog started enthusiastically, I had as many as 14 posts per month. Taking into account that blogging was only a hobby, I blogged like crazy. Then I went silent.

No, I wasn’t tired from blogging, I didn’t experience a writer’s block, quite the contrary! I was working on a project. A top secret one. Now it has been done, and here are the results:  a book called Implementing Microsoft Dynamics NAV 2009.

The book is co-authored by my friend David Roys, a.k.a. Gaspode, and me, and it discusses the freshly released Microsoft Dynamics NAV 2009: the new architecture, the RoleTailored client, the implementation approach, the dos and don’ts, with a lot of examples, tips and tricks and insight into the new version. I am definitely biased at this, but I’ll say it nevertheless: it’s worth a read.

The book is targeted primarily at consultants, those starting with the product, and those having experience with it already but wanting to learn the new ways the latest release has introduced, and those who want to quickly understand the new features.

The book will be published by PACKT publishing this month, and it has just been announced on its publisher’s website. Go check it here, see if its worth your time (I assure you it is; I offer no money-back policy though ).

For me, it’s time for a break now. From writing books, that is.

You are consulting for a customer, and they ask you:

- “There is a problem with setup for this item, when I calculate the requisition plan, the system suggests purchasing it, while I have it on another location, and I’d like it to suggest transferring it from that location, instead of purchasing it. Can you fix it?”

Assume you aren’t completely sure in the answer. What do you say to them? What do you do?

This is what I’ve seen consultants do if they don’t know (or aren’t exactly sure):

1. “Now let me see.” (You open the item card and go to the Planning tab) “This field should be filled in” (you set the Lot-for-Lot Reordering Policy, then go and recalculate the requisition plan) “Hmm, it still suggests the purchase, instead of transfer… Let me think. Ah, yes!” (You go back to item card, open the Replenishment tab) “We must set the replenishment system to transfer, then it’ll work…” (you go to Replenishment System field and find out it only allows Purchase and Prod. Order values—no Transfer) “Hmm, strange, I know it should be here somewhere…” (you recalculate requisition plan just for the heck of it; expectedly it still doesn’t work) “Er, I think I… or not… Aah, I’ve got it! Sorry!” (you give a broad hopeful smile and go back to the item card, open the planning tab) “There is a field here… hm, this one? Nah, it’s this one. Uh…” (scratching your head). “Where is that setting gone, I know it was here in the previous version, they’ve move it around with every new version, you know…” (fiddling with other tabs on item card, checking every single field). “Aha, yes! I know. There is this stockkeeping unit functionality, there you can set this up!” (you configure a new stockkeeping unit, go to Replenishment tab, check the Replenishment System field, and with the relief of an attendee of a seven-hour-long private audience with the Pope after water-drinking competition, you find out there is Transfer option there, so you choose Transfer, then go and recalculate plan again). “Uh-oh, it is Purchase again, and I’ve configured Transfer there…”. (scratchy-scratch) “Ah, but of course!” (you get it now, finally, phew!) “… how could have I missed that one – I didn’t set up the correct location in the stockkeeping unit card – you need it BLUE, I made it RED, let me fix it!” (so you fix it, recalculate plan and get a big fat error message saying that the Location ‘’ doesn’t exist.) “Uh…” (you do, or don’t do more retries; at this point it doesn’t really matter anymore)
2. Or you just say: “I don’t know how, but let me check and come back to you. Would tomorrow be alright? How urgent is this?”

Let me asses the quality of these responses.

Response #1 is a disaster. It’s incompetence materialized. It ruins the trust your customer might have in you. You have exactly one chance to exhibit this performance, and you are doomed; it’ll take a lot of big successes before your customer starts trusting you again. Compare it with a surgeon: “Ah, spleen. Now where is it? Ah, here it is. No, it’s a kidney. Hmmm. Spleen. I know I’ve seen it in books, it should be right there…” How many times do you think you’ll want to try your chances on the desk of this guy?

While at first you might feel the thrill of solving the problem for your customer right there. But if you aren’t 100% sure you know the answer, or the solution, don’t go there. You might give it a try, but if it doesn’t succeed after the first try, give up, and do the response #2.

Don’t make the second attempt, don’t try this then try that. While customers might forgive you (and probably will) your first unsuccessful try, your second one will be frowned upon. At the third one, I don’t want to be you. Simply go for #2.

Response #2 is good. Not knowing is not the same thing as incompetence. Not knowing is completely alright, provided you don’t answer every single question that way, at which point I don’t want to be you again.

Why does this answer work? I can think of these:

• Honesty: If you don’t know, and say you don’t know, you are candid, and honest, which are qualities customers value. Customers prefer honest answers to faked ones.
• Gauging: Customers want to know what they can expect from you, what is your level of expertise. If you try #1 and it succeeds (but out of sheer luck, not because you knew it), you make an impression of a highly competent consultant. They might ask you more complicated things, you might have luck again. Their impression and esteem for you go even higher up. At certain point, you’ll flunk, and then you’ll collapse. Big. And loud.
• Timeline: Your customers don’t always need the answer here and now. They might have an hour, or a day. Or a week.
• Solution: Like it or not, the solution is more important to your customer, than your perceived competence. Having a solution tomorrow is much better than having an impression of an incompetent faker today. Even if it is urgent, they will let you know, and if you sit and look through help file and find the solution, or call a colleague who’s a subject-matter expert, your esteem will get a boost. In the end, they’ll remember whether you’ve solved their problem, and whether you did it smoothly; they won’t care if you had to lookup the solution in the help, or to try it out at home, or ask a colleague—as long as you solve their problem.

(Thanks to Dave, who made an important point in his comment to my last post; that comment actually made me write this post)

Thought of the day:
I know everything, but not everything at the same time. It’s the virtual memory problem.

My last two posts have been a detour from my regular themes, into something that might remind you of human resources. I’ve explained what Microsoft Dynamics consultant does, and how it looks through phases of Sure Step implementation, and I promised to conclude this journey with explaining what I believe to be the 5 most important qualities every great Microsoft Dynamics application consultant must posses. So, here you go.

To be a great Microsoft Dynamics NAV consultant, you must exhibit the following skills:

1. Industry expertise
2. Application knowledge
3. Creativity
4. Patience
5. Communication

These are not all the skills, but these are most important. And the order is not arbitrary, I sorted them by importance I give to each one of them.

Let me explain them all, one by one.

Industry expertise

You can’t be a good consultant without being the expert in the industry for which you are consulting. The higher your level of expertise is, the better. Preferably, it should be higher or equal to that of your customer’s. Otherwise, how can you truly help?

If there was one thing that you must provide your customer from the very beginning, it’s the trust. Your customer must trust you, otherwise there is only a short path ahead of you. There is no better way to gain trust, than giving your customer reassurance and confidence that you’ll really understand their problems, and their business.

Your customer isn’t hiring you to install and configure a software for them. Not only for that. You need to solve their business problem, and to be able to do so, you must be able to fully comprehend the extent and the depth of the problem.

If you are an industry expert, you can give valuable insight to your customer, especially if your level of expertise is higher than theirs. You can then help them solve the problem in a better way, or give them a better perspective. Your expertise and experience will give your customer reassurance in your judgment; you know exactly why certain approaches work, and why they don’t work, and can always help your customers understand them better

Of course you can implement NAV without knowing the industry, but then it’ll take longer, it will bring more risks because uncertainty is all over the place.

There are various ways to gain the industry expertise: by working in the industry, and by working for customers in the industry. The best consultants I’ve seen have had extensive hands-on industry expertise gained through jobs they worked in the industry: the best accounting consultant I met was an accountant; the best warehouse management consultant I met worked as a warehouse foreman before he became an NAV consultant.

You can gain this experience through projects, as well, but don’t assume you are an industry expert just because you have worked on one project. On one project you never see it all. Only after two or three projects you start getting the feel for the industry.

Application knowledge

This one is so obvious that I won’t spend too many words explaining it.

You must know the application inside-out. Consider it for a second. It’s not about being able to configure the application, but to be able to suggest the right solution approaches. You must know what Microsoft Dynamics NAV can do, and what it can’t do, what it is good at, and where the threats lurk. You must know what impact your solution will have on other parts of the system.

Without application knowledge, you may seem incompetent, and this incompetence will stand out when it comes to solution design, configuration, training, everything. And there is no better way to losing your customer’s trust, than exhibiting incompetence.

Thankfully, of all these five, application knowledge is the easiest to gain. You only need to sit down, and learn the application. There are hundreds of pages of documentation, extensive on-line help file, and numerous trainings available. Don’t miss on this one.

Creativity

There are no my-way-or-the-highway approaches in implementing Microsoft Dynamics NAV. Being an industry expert, and knowing the application to the soul, still doesn’t mean you are the best consultant out there. You need creativity.

You need creativity to find workarounds when out of the box features don’t seem to work or solve a problem.

You need creativity to combine several seemingly unrelated features to achieve a goal, which seemed unattainable.

You need creativity to think outside the box, and find solutions outside the boundaries of the application or system itself.

Without creativity, why should anyone hire you?

Patience

As a consultant you are spending time with all sorts of people. You’ll meet people you like, and people you dislike, compatible and incompatible. It’s not about those who you like, and who you find compatible—these are no problem. It’s the other ones you must be able to cope with.

You’ll meet difficult people. You’ll meet people whose characters will annoy you, or irritate you, or whose general attitude is outright repulsive to you.

You’ll meet people who’ll be slow thinkers, you’ll need to work with them over and over before you start speaking the same language. You’ll meet users who just won’t get this new application. You’ll meet those who simply won’t want to.

You need to be able to work with them all.

Full time. Day over day. Week over week. For a month. Or a year.

And you must be able to gain and maintain their trust throughout.

Without patience, you are not going to go very far.

Communication

Finally, communication. Communication is your full time job. Whether you talk to your customer, write e-mails, or requirements or specifications, you communicate. In written form, or verbally, formally or informally, you communicate all the time.

You must be master of conveying your thoughts.

But you must be a master of understanding other people as well. And it’s not about what they say, it’s about what they don’t. You must be able to catch their body language. You must be able to get what they mean even when it is difficult for them to express themselves.

Questioning is an important aspect of communication. Getting to the core of the problem can be difficult, and you must use the power of the questions to get to the point, and stay at the point, especially when you are gathering and analyzing requirements.

You must also be able to convince your customers that the solution you believe is right is truly right. You don’t do it by arguing, or emphasizing, or stressing, or trying to convincing them. And you definitely don’t do it by being right. You do it by making your customer come up with your ideas as if they were their own. Again, questions are impressively good at achieving this.

Your communication style should be adaptable as well. You’ll work with top management, executives, accountants, salespeople, forwarding agents, forklift drivers and machine operators. And you must be able to speak their language and adapt to them, connect to them. With white-collar and blue-collar alike, you simply must not be too smart, and definitely not too stupid, you must be just right. And you must be able to know what just right really is, because there is nobody there to tell you, other than yourself.

There you go.

Now that I’ve described an Übermensch, do I know anyone who is exactly this? No, not really.

But you don’t have to be a total ninja at all of these, you need to have a fair balance, and more than everything to know your strengths and weaknesses, so you can focus on emphasizing the former, and mitigating the latter. In the end, it’s all about improvement, you must improve on all of these with time. With every project, and every customer.

I’d like to hear your opinion on these. And more than anything, I’d like to know your top 5, or top 10, or top 3 qualities of a great Microsoft Dynamics consultant.

Yesterday, in my What does a Microsoft Dynamics consultant do? post I started explaining the job of an application consultant. As promised, today I’ll explain what duties an application consultant has in each of Sure Step phases.

So, here it goes:

• Diagnostic phase: Even though this phase is mostly about sales, an application consultant is as busy in this phase, as in any other. The goal of this phase is to prove to yourself and to your customer that Microsoft Dynamics (NAV or other) is the right solution for them. This is done through a series of decision accelerators, most of which require active participation of an application consultant. Application consultant must gather the requirements, conduct the Process Review and Fit Gap workshops, because these two activities require extensive knowledge of the application. Also, during the Proof of Concept activity, an application consultant helps take the users on a journey through a prototype of their future solution.
• Analysis phase: Requirements analysis workshops require intensive engagement of application consultants. When you are talking to your customer about their processes and requirements, you truly depend on your application consultants’ knowledge of the application and of the business problems they are solving. Application consultants map customer’s requirements to standard application and define solution approaches. They also need to set up the application for, and conduct the key user training, so they should have good presentation/training skills as well.
• Design phase: Application consultants also design solutions for identified requirements. This doesn’t mean that they have to design data models or business logic (this is something that developers and technology consultants do), but they have to write the functional design documents both for new functionality (to explain the changes made to the system) and for existing functionality (to explain the system configuration which has to be made to achieve desired functionality). Obviously, at this stage they also have to define system configuration, and make sure it really works. They do it by setting up a system, and testing it thoroughly—it’s their responsibility to discover any hidden gaps between standard functionality and customer’s requirement, that wasn’t obvious during fit gap analysis itself.
• Development phase: As developers develop, application consultants test. They test application features, data migration accuracy and processes. They also have to prepare for deployment, and define test scripts and scenarios for final system testing and user acceptance tests. They must make sure that these tests include testing all relevant configuration settings.
• Deployment phase: In this phase, application consultants configure the production environment according to specifications they wrote earlier, and they assist key users in conducting system and user acceptance tests. If there are any train-the-trainer activities planned, they again have to train the trainers (those people who later conduct the end-user training). If a customer is small, application consultants might have to deliver the end-user training as well, which is a difficult task: they may face indifference, absentness, lack of interest, lack of cooperation, or downright obstructive behavior, so they must posses strong social skills and be prepared to handle issues and difficulties.
• Operation phase: After the system has gone live, application consultants have to work with the key users, and sometimes even end users, to help them master the new application. They must be well versed in both the application and logic of the business: they will have to correct a lot of errors that happened because users won’t just at once fully understand the application.

An application consultant should also better be a heck of a good typist, or have a secretary to do the typing for them, because an they’ll have to write huge amounts of documentation in all of these phases. Functional specifications, analyses reports, design specifications, test specifications, user documentation, you get the picture.

So, the job of an application consultant provides a lot of diversity and challenge, and will provide you with a lot of experience you can use in many other job roles when you get enough of implementing Microsoft Dynamics NAV.

I’d dare say that not everyone can be a good application consultant. Being a good application consultant requires a few skills, and to find out which, come here tomorrow and read about top 5 qualities of a great Microsoft Dynamics consultant. See you!

I wonder what people do with Google (or any other search engine for that matter) results past page two, or three. Or ten.

The other day a visitor came to this blog by googling this question: What does a Microsoft Dynamics consultant do? Two things I don’t understand: first, how far in the search results did they have to go—my blog most certainly didn’t land on first ten pages; and second, did they find here on my blog what they were looking for?

I decided to improve both.

Indeed, what does a Microsoft Dynamics consultant do? To answer this question, I’ll write a series of posts, and I’ll explain what a Microsoft Dynamics consultant is, and does, and I’ll explain top 5 qualities of a great Microsoft Dynamics consultant.

So, to start with, Microsoft Dynamics consultant is not a uniform species; it comes in many varieties. Two most common are application consultant, and technology consultant. As per Sure Step, there is a third one: development consultant. I wouldn’t personally call developers consultants, but I’ll comply. With one particular partner company I once worked with, almost every Microsoft Dynamics NAV role had two qualifiers: consultant and manager. So if a developer wants to be a development consultant, it’s ok as long as they aren’t a development consultant manager.

Application consultant’s role is the central role in every implementation project. They are also primarily focused on customer. At the beginning of a project they spend most of their time with the customer, discussing the requirements, analyzing them, and documenting them, focusing on understanding how to map these requirements to standard application functionality.

They must understand the application well; they have to be able to recognize that a requirement can be met with this or that specific feature, and to what extent it will have to be customized to fully meet the customer’s needs.

Then they spend a lot of their time communicating with the development team, and explaining them the customer’s requirements,  and what has to be changed in the system to meet them. They make sure that what developers have produced really complies too all the specifications they (the application consultants) have written.

They do a fair amount of testing: they prepare test scenarios, help in preparing test scripts, and personally conduct feature tests, function tests and process tests. The assist the customer in conducting final user acceptance test, and they deliver key user trainings.

They also configure the application: master data templates, posting groups,  categories, modules configurations, supplementary data, security roles, all sorts of stuff. They make sure that the application really works as specified.

Technology consultants do a somewhat different job. They are still primarily customer focused, and they spend a lot of time working with customer. They must know the Microsoft Dynamics application from technology perspective inside-out, they must understand the infrastructure requirements, as they will give recommendations about retaining existing hardware, software or network infrastructure, or about obtaining new one.

They work closely with customer’s IT department: they assist them in preparing the environment, installing necessary prerequisites, configuring operating system and database server.

Technology consultants have two important responsibilities: performance and scalability. They must ensure that technical recommendations they make really result in sufficient performance for the customer, otherwise customer’s productivity may be hindered, and they also must provide a scalable architecture which will allow the customer to grow, both in transaction volume and number of users working in the system.

An important task for every technology consultant is not only to know the technology of Microsoft Dynamics, but to know and understand and preferable have a working knowledge of the whole stack of Microsoft technologies. They use this knowledge to give recommendations both to customer and to application consultants regarding requirements which can be better met with various integration approaches.

They also design and develop data migration, integration and interfaces, and work closely with development team during design and development to make sure that technology requirements are observed and that chosen technologies are utilized to the full extent of their potential.

All in all, the Chinese curse May you live in interesting times really applies to Microsoft Dynamics consultants, and from the perspective of this proverb, Microsoft Dynamics consultants are—cursed!

Come back tomorrow for more in-depth explanations of what does a Microsoft Dynamics application consultant’s job look like through various phases of an implementation project.

In on of my earlier posts here on this blog, where I was merely testing out my theories, I said that user interface is one of the biggest drivers of return on investment: a familiar, easy to navigate, non-cluttered user interface that truly allows you to focus on your work, and not spend too much time meddling with hundreds of options, never being really sure which one to click (okay, I exaggerate, but don’t worry, that’s on purpose)—wouldn’t something like that cut down employee ramp-up time significantly and boost the productivity?

Well, now it’s here, and it’s called the RoleTailored user interface. Or experience, whichever you prefer.

Take a look at Susan, she is a sales order processor at Cronus International, and every day she starts with checking the quotes from previous day, making sure they are ready for making into orders. She then checks for any open orders which can be released for shipping and invoicing. Then she checks the orders ready to be shipped, then those that have only partially been shipped, and pays special attention to those that have been delayed. When all this has been finished, she takes a look at the returns and handles them, if any.

In Classic interface of Microsoft Dynamics NAV, this required a lot of clicking around, filtering and came with high probability of lost productivity: Susan would set an incorrect filter, getting an empty list instead of one with 25 orders requiring her attention, which she would frequently find out only at lunchtime when her boss called her in frustration asking here why these customers haven’t already been served. Then she would burst into tears, because she never really understood how to set all those filters—there were so many of them.

Now that Cronus upgraded their database to Microsoft Dynamics NAV 2009, and the RoleTailored interface was introduced, Susan only needs to click a button before she gets exactly where she needs to get, and she can handle all these tasks before morning coffee. Her boss has been so impresses with her increase of productivity that she recommended Susan for promotion. No wonders why, this is Susan’s home page:

She immediately sees where to click, and getting anywhere is always a single click away. No more frustration over filtering—she never actually has to set a single filter, all of this is taken care of by the RoleTailored user interface.

Right in the middle, there are her Activities, the place where she simply starts clicking those large icons, telling her exactly how much work she can expect at a certain task, which helps her planning her activities. She doesn’t have to spend three minutes setting and resetting filters only to find out that there are no partially shipped orders to take care of; right there in the middle of her home page, there is a button telling her exactly that:

Before, if she saw an empty list of orders, she was never sure whether the list was empty just because it was empty, or because a wrongly set filter was making it look empty. Now she is always sure. She never makes mistakes, she never misses a single order. She rules. She feels great.

And it’s not about Susan. It’s about every single employee in the company. For each of them, their home page, or Role Center, tells them exactly what they need to do, helps them prioritize their tasks, see and respond to action items. No more time lost on searching for correct button, or wondering whether right filter was switched on. The system helps everybody focus on their job, rather than focusing on and handling the software.

RoleTailored experience didn’t just come out of blue, as an experiment that Microsoft has decided to conduct. Actually, Microsoft has spent several years researching how users use systems, what they do, where they spend their time, and how they think and react when using software. They researched companies and their processes, and identified groups of users, called roles, so that a viable customer model could be built right there, into the user interface and the application itself, so that every new deployment of Microsoft Dynamics solutions can go smoothly, and provide faster adaptation time, less time spent on training users for new interface. The product of this is the RoleTailored interface.

If you want to learn more about RoleTailored experience and how it enhances user productivity, I suggest that you read the Microsoft Dynamics RoleTailored Business Productivity whitepaper. I also suggest you read the blog post about RoleTailored experience, that Vibor Cipan, a member of Dynamics User Experience team in Copenhagen, and a good friend of mine, posted on his blog UXPassion.com.

I also plan to cover this topic in a lot of detail here on my blog, so stay tuned for more content in the following weeks.

(A short rant about eye-contact-based specifications.)

In short, there is no such things as an eye-contact-based specification. And for a reason.

While kicking-off of a project, we had a discussion with the customer about the change management approach, and specification detail. I was insisting on documenting all change requests in detail and update the specifications accordingly, but the customer went:

- We don’t need to specify every single detail, and every single tiny change. Specifications should be high-level, so that they can stay unaffected with detailed changes, and we can agree on details on the go.

- But what if we agree on a detail on the go, and later you say you wanted it the other way around? – I asked.

- We are grown ups. – said the customer – That won’t happen. If it happens, you come to me, you look me in the eye, I look you in the eye, and I tell you what I need, and I assure you that request won’t change ever again. And that’s as good as written specification. Specifications should stay high-level, small details shouldn’t go there. If we spend time documenting every single detail, we would burn the whole project budget just on paperwork, changes and approvals. We just need to look each other in the eye and trust each other’s word.

Now my eyes hurt.

My brain does even more so. If customer is king, I ended up a jester.

Take my advice: Don’t give in on methodology.

The long awaited Microsoft Dynamics NAV 2009 has been released for download earlier this week, and has just been publicly announced at Convergence 2008 Copenhagen. If you have PartnerSource access, you can download Microsoft Dynamics NAV 2009 here.

This one is the most important release of Microsoft Dynamics NAV ever, as it brings a completely new architecture, a shiny new user interface, web-services enablement and much more.

The product is currently available in worldwide (W1) version and 13 localized releases in 9 languages.

Unlike any previous versions, this one is not focused on delivering new ERP functionality. From functional perspective it’s the same application as Microsoft Dynamics NAV 5.0 SP1, and no new application features have been introduced.

This has been a strategic move by Microsoft to help customers migrate to new platform easily without too many costs typically incurred by upgrade projects: customers upgrading from version 5.0 SP1 will merely have to upgrade the user interface. Thanks to the data model and code equivalence of versions 5.0 SP1 and 2009, business logic and data model is something that won’t need an upgrade, making for smooth, low-cost and low-risk upgrade projects.

What’s new for the customers in the new release. Truly a lot, but I’ve picked these three as having deepest impact:

• User Interface: The RoleTailored interface is a product of several years of Microsoft’s investment into research of user interaction. RoleTailored interface hides the complexity of underlying business logic from users, exposing only those functions pertaining to user’s role. The new user interface is much more intuitive and self-explanatory. Also, users will have one-click access to most-used functionality through Role Centers, organized dashboards which give direct insight into pending to-dos and tasks requiring user’s attention. Accessing one’s daily work doesn’t require browsing through labyrinths of screens and menus—typically, only what’s needed is shown in every screen, and there are vast personalization capabilities to make it all even simpler.
• Web Services Enablement: It is now possible to expose any Microsoft Dynamics NAV functionality as a web service without any programming allow Microsoft Dynamics NAV to be seamlessly integrated into workflows extending far beyond system boundaries. Company’s internal processes, line-of-business applications, business-to-business and business-to-customer interactions can now be streamlined with significantly less investment into development and testing.
• New Architecture: A completely new, 3-tiered architecture with new Service Tier introduced, a middle component which executes the business logic. This lays the foundation for more robust, scalable and concurrent solutions. New architecture allows for much more freedom in designing network infrastructure, and there will be less scenarios where Terminal Services were the only viable option. Also, higher scalability is now much easier to achieve, which means that Microsoft Dynamics NAV will be able to sustain growth of customer’s business much longer, preserving the investment.

Microsoft Dynamics NAV 2009 is going to be a hot topic of blogs, news sites, articles and analysts’ reports, as it makes the important step towards a single Microsoft Dynamics ERP platform: this is the second Dynamics flavor, after AX earlier this year, which sports the RoleTailored user interface, the new standard for all Microsoft Dynamics ERP products. While not a goal in itself, converging products to a single solution once a uniform user interface is available across all four ERPs will be made into a possibility, or a certainty, if Microsoft chooses so.

I will be attending Convergence 2008 Copenhagen this week. It’s the premier Microsoft Dynamics event, bringing together customers, partners and Microsoft, to share experiences, gain insight into latest developments, discuss solutions and build community.

There are two Convergences each year, a European one traditionally held in Copenhagen in fall, and a US one, traditionally not held at the same place, but always held in spring.

You can read more about this week’s conference content at the Session Catalog, but as a gist, it covers Microsoft Dynamics technologies represented in Europe (NAV, AX and CRM), plus some related technologies such as Dynamics Mobile, Business Intelligence, Office. Also, there are sessions about Microsoft’s application platform in general, Dynamics solutions in vertical industries, environmental sustainability, and business leadership. All in all, from geeks to executives, there is something for everyone.

I’ll be mingling about NAV presentations, so if you are attending as well, catch me around. (Or drop a comment here, and let me know where I can catch you. I’ll keep these comments private.)

I’m looking forward to meeting you!

Last Friday, while enjoying a not-at-all healthy Salisbury steak with cheese, I had an interesting discussion with a partner: should NAV consultancies create default databases?

A default database (in this context) is a packaged solution built upon standard Microsoft Dynamics NAV, where a consultancy has introduced a number of features that they sell to all their customers as the standard solution, instead of standard NAV. The modifications to standard NAV can range from simple report adornments to minor feature improvements  to full-scale horizontal or vertical functionalities.

The partner offered a resolute No, while I was more inclined towards a Yes, why not approach.

I believe there is no definite answer to this question, and there are numerous pros and cons to default databases. I understand many consultancies, especially new ones, are adopting either approach without proper understanding of all implications: either they jump into reinventing sliced bread by modifying NAV all over, or they stick to holy scripture of standard C/AL.

If you have grounds for either approach, good! But if you do either way, and don’t know exactly why, you might reconsider your practices. Here I’ll try to analyze the pros and cons, so if you don’t (yet) have an opinion of your own, you are free to adopt mine Of course, I’d like to hear from you, so if you do have an opinion on this topic, please comment on this post.

Let me start with the pros:

• Repeatability: This is the most obvious benefit. You can give your customers more cowbell for only a slight increase in price tag. If you find yourself doing the same customization over and over for different customers, maybe you can make it more affordable for them by packaging it up into your default database, and start projects from that database, instead of from  standard NAV.
• Specific concepts: NAV is a very generic solution. It supports most of typical ERP processes, but at a very generic level, and to successfully put them to work you frequently need to do some C/AL. A good example (up until recently, anyway) was purchase approval workflow: many customers asked for it, but it wasn’t included (now it is). If you had this functionality in your default database, you could easily enable it if your customers needed it, and do so at a much lower cost than if you had to start from scratch..
• Vertical edge: If you plan on targeting specific verticals, your projects can benefit a lot if you start from a default database which covers some specific requirements up front. This applies in reverse logic as well: if you have developed a few specific highly vertical features, you increase your market edge and the likelihood of landing a project with customers in these verticals.

On the other hand, there are very loud cons:

• Discipline: With a default database, you need extreme discipline in doing your projects. It is very common that consultancies end up with more default databases than there are customers (one “default” database per customer, and a couple of in-house development/staging/testing ones). When you decide to have a default database, then you should not only keep improving it for your future projects, but you should deploy the improvements to all your existing customers, and never do development of default database in parallel with implementation projects. Otherwise, the default database will backfire in maintenance costs.
• Maintenance costs: If you decide to create a default database, you must have a dedicated person to maintain it (maybe not immediately, but after a while, you most certainly do.) This person must maintain a single default database for each official release of NAV, make sure that these versions are upgradeable, and that all of the default customizations are deployed to all customers. This can easily introduce significant overhead which outweighs all the benefits of default databases.
• Upgradeability: By building a default database you make future upgrade projects more costly for your customers than they should be in the first place. If you start your projects with a pristine NAV solution, you have a common and a very clear starting point of all your customizations, so upgrades are easy. On the other hand, if you have a default database, in addition to maintaining it, you need to maintain as many upgrade toolkits as there are NAV versions deployed with your customers.
• Copyright issues: Depending on your contract with customers, some customizations might end up being their intellectual property, not yours. This can raise issues with default databases and cause unnecessary disputes. But this can be sorted out at legal level, it has nothing to do with NAV itself.

Any of these arguments can be refuted at length, and there are many counter-arguments you can make against each of them (please do!). If you went like “I disagree” while reading any of the above, it only proves that there is no one-size-fits-all approach to this topic.

However, there are a few good practices that can be put to work regardless of which camp you belong to:

• Default setups: Instead of touching the standard C/AL code, you do default setups. Things like default charts of accounts and posting schemes or functional areas setups for specific verticals, supplementary data setups (such as currencies, payment terms, etc.), number series, etc. This can save a lot of implementation costs, and leave the standard business logic untouched. It makes your projects repeatable, while not affecting upgradeability or maintenance costs at all.
• Default RIM templates: You may streamline your projects by preparing RIM templates for specific verticals, or by adopting them to your local market conditions. This makes your projects very repeatable, and decreases overall costs, while not introducing any of the issues of default databases.
• Default objects: You package some default features, but don’t include them in your projects by default, and you only include them upon customer request. This still increases repeatability, but is much lighter on your maintenance costs, and upgradeability.

Combine these three, and you have a winner!

But you can have a winner by adopting a default database approach, too! Actually, you already have it: it is called Microsoft Dynamics Entrepreneur Solution. It is a Microsoft’s “default database” approach with NAV for small customers: a shrink-wrapped ERP based on NAV standard functionality, which targets small customers with little interest in customizations. A highly effective way of targeting a specific market segment. This proves to me that default database approach can be a very sound one, and very profitable for its successful adopters.

There is absolutely no reason you can’t adopt the same approach by developing your entrepreneur solutions. If you are an ISV (or planning on becoming one), instead of developing your very own ERP system from scratch, why not starting from a highly customizable ERP platform (which NAV truly is), and turn it into a more specialized ERP solution that you market to a specific market segment. If ISV’s can build a stable business model by developing ERP systems from scratch, I bet you can do more by starting from a more than a solid foundation. Give it some brainpower!

I’ve been blogging about Sure Step, talking about Sure Step, learning about Sure Step, teaching Sure Step, evangelizing Sure Step, here on this blog, in online columns, at conferences, presentations, (pre-)sales calls, with partners, with customers, in one-on-one contacts, e-mails, Linked In, Facebook, Squidoo (haven’t tweeted about it yet, but that’s to come).

I believe in Sure Step.

But what I think might not be important at all. I am just an average joe out there voicing his opinion.

What do you think of Sure Step?

Has it worked for you? Has it not?

What do you like about it? What don’t you like about it?

Why?

Go ahead, share your thoughts!

One of many improvements the latest version of Microsoft Dynamics Sure Step methodology has brought along is the revised purpose of the Functional Requirements Document (FRD). This document has long served as cornerstone of every Analysis process of every implementation project: it was the main deliverable of the Analysis phase and it both documented customer’s requirements and explained how they will be met with Microsoft Dynamics NAV solution.

Typically, it was first drafted after detailed Gap/Fit Analysis has been conducted. If a project was a complex one, this was some time half way through Diagnostic phase; generally it wasn’t until early Analysis. In any case, it always followed the Gap/Fit Analysis, and served as a detailed explanation of:

1. Business processes relevant for the new solution
2. Results of Gap/Fit analysis: resolutions for gaps and configuration for fits
3. Data migration requirements
4. Data integration requirements
5. Software and hardware requirements
6. Security requirements
7. Testing requirements
8. Training requirements

Obviously, this document didn’t only answer the question What, but to a significant extent it also dealt with How, especially, in the gap resolutions and fit configurations.

When it was completed this document was probably closest to what PMBOK refers to as Scope Statement: it specified the detailed product and project scope, and served as basis for development of project work breakdown structure. Finalization and customer acceptance of this document was a major implementation milestone: it marked the end of Analysis phase, and moved project further to Design phase.

And now for something completely different.

Latest version of Sure Step has redefined the Functional Requirements Document and considerably changed its purpose.

Let me try to sum up the major differences between old and new Sure Step view of FRD:

1. In (new) Sure Step, you will never draft a Functional Requirements Document during Diagnostic phase. The closest the Diagnostic phase will get you to functional requirements is the requirements worksheet, called Functional and Non-Functional Requirements Spreadsheet. This document will later serve as input to many requirements document you’ll write during Analysis phase.
2. All non-functional requirements have been taken out of this document, and moved to another document called Non-Functional Requirements Document. Main difference is that functional requirements address business processes and how they map to standard solution, while non-functional requirements address primarily infrastructure: security, integration, platform, interoperability, performance, etc.
3. Functional Requirements Document now only answers the question What. It explains what must be achieved in the new system, and it doesn’t bother with explaining how.
4. Functional Requirements Document is now input to detailed Fit Gap Analysis (notice that Gap/Fit Analysis has been renamed to Fit Gap Analysis). This is a major development of FRD concept: since it merely explains what are the requirements, the task of detailed Fit Gap Analysis is to explain how these requirements will be met—and only to an extent, final answer to this question comes in the Design phase when design documents are written.

Functional Requirements Document is still one of the central documents of the Analysis phase, however it’s focus has been narrowed down, and its purpose has been redefined. Its position in the analysis process now seems more logical: it makes more sense to document the requirements in a structured, understandable and presentable way, and then to analyze them in detail against the standard functionality of Microsoft Dynamics NAV. How a requirement will be met doesn’t have to be documented together with the requirements, and it is better if it is documented separately elsewhere.

In my opinion, with Fit Gap Analysis being conducted after Functional Requirements Document has been finalized, the flow of Analysis phase is more logical: scope is determined first, then it is developed and clarified further during Fit Gap Analysis.

Don’t you just love when users come up with new feature ideas at a microprocessor clock rate. Even before you finish developing one, five new requests pop up. This is a disease, and it’s called featuritis!

Featuritis doesn’t mean the features are just sporadically requested and developed ad hoc. Oh no, this process can be totally “controlled”, all these requests can as well go through a proper change process, with requests, analysis, approvals, papers circling about. When it comes to changes, some customers behave like they have have unlimited budgets. In the end, these requests pile up on your desk. And most of them smell one-off.

What do one-off feature requests have in common? A few things:

1. They are all requested by a specific somebody who needs to accomplish something, but doesn’t know how to do that the easy way around.
2. It can be accomplished an easy way around.
3. Nobody else needs it, because it is either not necessary at all, or they know how to accomplish it the easy way around.
4. These features don’t see much runtime. They are typically used only once…
5. … provided the user who requested the feature didn’t already figure out how to accomplish it the easy way around, while  waiting for the developer to deliver it.

So, what do you do with these features? What a question! You develop them, of course. What else would you do? They have been officially requested, they have been officially approved, so they better get developed.

Once I worked on a project where new report requests were popping up like popcorn, and all of them were routinely approved by customer’s project manager as “critical”. Once they needed these two columns, then another two columns, then grouped by this field, then by another. I fought and lost too many battles trying to explain how extracting data from NAV to Excel does a much better job, but it didn’t work out–the customer wanted it “all integrated”. So I kept the developers busy.

It was curious that the customer never ever complained about any issue whatsoever with any of these reports after they were developed. With reports, there are usually several cycles of improvements: add this, remove that, rearrange columns, make bold, but with these, nobody ever complained. Not this time, not with this customer.

Even more curious was that during an inspection one day, I decided to personally test some of the reports, so I ran them, and many of them threw an error at me immediately. I opened them only to find that the very first line of C/AL code in the OnInitReport trigger was something along the lines of this:

It was generic enough not to raise any suspicion of the prank, and looked serious enough to solicit a phone call to support. But guess what, nobody ever called to complain about this.

When I inquired about this, a developer told me: “I did it on purpose, just to see whether the users will complain.” The fact that they didn’t, proved that these reports were totally unnecessary in the first place, and the problem that triggered them was solved in the meantime (or forgotten about altogether).

This little prank the developer pulled on the customer was a fantastic cure for featuritis–it showed with mathematical precision how many of these “critical” and “must-be-integrated” features really were needed, and how much money actually was wasted.

Now, I most certainly don’t suggest or advise that you do something like this, there are far better ways. However, when your customer exhibits a slightest symptom of featuritis, if you are on really good terms with them and their project manager doesn’t believe all those requests aren’t really necessary, you might try it just to prove your point.

P.S. Two ways are far better:

1. Don’t actually program any errors: simply “forget” to compile the object. This is much less obvious.
2. Develop a feature usage tracking functionality, and log every usage occurrence. Two months into deployment of any feature, you can send to the customer a nicely looking report showing exactly how many features just sit there waiting for someone to start using them.

Some time back, as I was riding a taxi from Prague airport to Holiday Inn hotel, I wondered about the fixed price I was about to pay for the ride.

- “Airport to city is 700 flat.” – said the driver when I asked how much approximately will it cost.

Common wisdom goes that flat rates mean you get it worse than if it wasn’t flat. Indeed, if it was on meter, and if the driver took the shortest route (I had a GPS device on me, I could’ve easily checked it!), the fare would’ve been lower. And yet, I decided I loved the flat rate.

Flat rate means that the risk is with the driver, if for some reason or other his costs exceed the fare (e.g. because of a traffic jam or a closed road), I end up paying the agreed price. Also, the driver will really do his best to take the shortest route possible, because he wants to earn the highest possible margin, so he’ll make extra effort to be as efficient as it gets.

On the other hand, when the fare is on meter, the risks are with me, and any detours are on my budget. The driver has no incentive to keep the costs low–he actually benefits from taking me on a sightseeing ride. I always carry a GPS, but yet.

Compare it to implementation projects. Flat rate equals fixed price, meter equals time & material. Which one do customers prefer? Of course, fixed price. Because it puts the burden of delivery on the consultancy. If consultants fail to deliver in time and on budget, it’s on them, and they will make extra effort to hit the mark. With Microsoft Dynamics implementations, customers don’t like it time & material based. The ultimate reasons is that time & material projects make it difficult to predict ROI.

The problem with implementation projects, as with majority of IT projects in general, is that they rarely hit the mark–they often exceed the allocated budget or trample over deadlines. So, it’s consultants who bear the risks, and if the customer doesn’t agree to extend the budget (why should they?) the consultants have to bite the bullet.

I have a theory about blowing budgets away and trampling deadlines: it happens not because consultants are incompetent, it happens because budgets and deadlines are unrealistic. The problem is estimating work and effort, and if you underestimate it, you are sure to blow the budget. (If you underestimate on purpose, so you can get the job, and you miss the mark, then you deserve to bite the bullet!)

If you are a consultancy specializing in implementing Microsoft Dynamics NAV (or any other Dynamics flavor), there is good news for you: Sure Step.

While Sure Step can’t make you estimate the work with accountant’s precision, it can get you very close to real figures. The tools available to you in the Diagnostic phase of Sure Step can help you calculate important numbers, such as Degree of Fit, which can give you a better picture about amount of effort you need to exert to get from here to there.

Actually, whole Diagnostic phase is packed with tools that help you build a firm picture about the project, estimate the work to be done, and make you feel more comfortable about fixed price. Specifically if you utilize Fit Gap and Solution Blueprint, Architecture Assessment, Scoping Assessment and Business Case decision accelerators (four out of five), I am fairly sure you’ll feel as happy about your next fixed price project, as I was when I paid 700 CZK to the taxi driver at the lobby of Holiday Inn, Prague.

Last week, my friend Dave Roys a.k.a. Gaspode has been awarded the prestigious MVP award. MVP stands for Most Valuable Professional, and Microsoft grants this award to distinguished professionals as recognition to their invaluable contribution to Microsoft community.

MVP award is not something an average John Doe can achieve–you need to work out a lot of sweat and make contribution that really matters. There is no recipe to complete, or requirements you must meet, you simply have to stand out so much to be noticed and recognized by the community as a trusted expert, and there is only a limited number of new MVP’s each year. For Microsoft Dynamics NAV, there is a total of 19 MVP’s worldwide.

This award couldn’t have come at a better time to better hands, than exactly now, and to Dave, who has done a great job maintaining his blog, and contributing with comments and articles to other blogs and sites about Microsoft Dynamics NAV. He has done much more, but I better keep my mouth shut. You’ll find out when the time comes.

Dave, congratulations! You earned this!

P.S. You can read Dave’s MVP profile here.

Recently, a reader, commenting on my last post about Sure Step, pointed me to an article by Karl E. Wiegers
“Read My Lips: No New Models!” I initially responded to the comment, but I figure the comments aren’t read as often as posts, so I decided to blog it.

It’s doubly funny that the reader is using Dr. Wiegers to devalue and dismiss Sure Step: firstly, the article has really nothing to do with implementation methodologies at all, and secondly, when I delivered Sure Step training at WinDays pre-conf earlier this year, I gave to each attendant a copy of Karl E. Wiegers’s latest book “Practical Project Initiation”—at the time it was the best book available that matched both the message of my training and the point of Sure Step as a methodology.

I don’t mind people dismissing an idea or an approach, especially if they reaffirm their position with argument. I like good argument and I like being proven wrong as much as I like proving others wrong. But dismissing something one doesn’t know anything about, from pure prejudice, with no argument at all, while hiding behind an authority (which doesn’t even apply), is lame. On the other hand, Karl E. Wiegers provides very strong argument in his article, strongly affirms his position, and makes several good points.

However, as much as I value Dr. Wiegers’s work, I respectfully disagree with most of this article’s content. From the point of ERP system implementation, it simply doesn’t apply, or it applies to it as much as Kepler’s Laws of Planetary Motion apply to particle physics. From the point of software development, it’s a good article worth reading, but I’d dare saying it’s a little bit outdated—much of what it argues for was valid points ten years ago when it was written; today with formal methodologies far more in use, I feel this article is beating a dead horse.

Let me start with Sure Step itself. Sure Step is not about software development. It would be foolish to say it doesn’t have anything to do with software development—it does, it contains a phase called Development (only one of six phases)—but it doesn’t care about how you design, or how you test, or how you inspect code (the topics of the article), Sure Step doesn’t care whether you use UML or FMC or BPMN or plain flowcharts for your designs, it couldn’t care less about your testing framework choice; instead, Sure Step describes what needs to be done to achieve success. What Sure Step is about is Microsoft Dynamics ERP and CRM implementation process. There is a huge difference between software development and business management systems implementation. Confusing these two consistently drowns implementation projects. I’d like to blog about this more, but not today.

I believe that Dr. Wiegers’s article starts off with a very dangerous statement to make: “with a few exceptions, the software industry does not need any more models right now.” Whoops! Slippery out there, ain’t it?

Call me an idealist, but I believe in improvement (so does Dr. Wiegers), and I can’t subscribe to the point of view I quoted above. Throughout, this article conveys this position: before you invent anything new, make sure you understand and apply current methods. Although I’d say you don’t need to master hammer before you start using jackhammer, I’d generally agree that if somebody doesn’t understand methods at hand, and if that person is not applying them, and if that person doesn’t understand what exactly about them works, and what exactly doesn’t, that person shouldn’t be seeking better ways.

But what about other people, those who understand the methods, who apply them and learn from them? To simply throw this article into their face is arrogant at best. Dismissing an idea, a method, an approach, a point of view or anything else for that matter, up front and just based on a single point of view is shortsighted, counterproductive and plain wrong.

And that’s exactly what Dr. Wiegers says he has done to “James Bach, a thoughtful and well-known figure in the software quality industry” the moment he started to explain his new testing model to him. I believe James Bach knows pretty well the existing models, and if anyone can and should research new models, it’s him and people like him. Yet, Dr. Wiegers simply dismisses his approach up front, as a generally wrong one. I don’t like this attitude. I am a challenger myself, and I like to put my advocatus diaboli hat on more often than not, but this is not a challenged idea, this is just naysaying and a pure progress-killer.

Sure Step isn’t a wheel reinvented. It doesn’t dismiss or declare war on any existing method—on the contrary: it draws from, and promotes existing frameworks, methodologies and best practices. PMBOK for project management, TDD for testing, these are just a few examples. Sure Step is not a new method, its combined knowledge and experience with existing methods, and their application to a very specific and a narrow field: implementation of Microsoft Dynamics solutions. You can’t develop web applications or business intelligence solutions using Sure Step, you can’t implement SAP or Siebel using Sure Step—it doesn’t apply to any of these although majority of methods and approaches included in Sure Step can apply to all of them. Sure Step is a specific methodology aimed at getting results in a specific field, and with very few other specific methodologies applying to that field and comprising so many useful and directly applicable tools and templates as Sure Step does, no one can tell me there is no place under the Sun for Sure Step. It’s not a “Yet Another Model” that “clutter[s] the market”, it has proven its value to many Microsoft partners and customers already.

Rebecka Isaksson wrote a nice blog post on Jonas Deibe’s blog about why there is need for Sure Step, and this proves to me that I am not the only one out there believing how valuable Sure Step really is. Also, Sure Step being the most searched for and read topic on this blog, despite the fact that it is only one of many topics I blog about, makes me trust there are many other people out there believing in the value of Sure Step as well.

To conclude, it’s not only about getting the job done (as the article might make you believe in its recap), it’s about getting it done better, faster, cheaper, more reliable, more predictable, you name it. If a method(ology) can bring this, then Read My Lips: How Can There Be No Room For It?

P.S. I wouldn’t be fair not to say that the reader whose comment made me write this post runs an excellent project management blog. I might disagree with one comment he made here, but his blog is worth an RSS subscription.

Each phase of Microsoft Dynamics Sure Step methodology is equally important in an implementation project. You could argue that analysis is the most important, or that design is the most important, or that operation is less important. I’ll paraphrase Scott Adams here and ask: how one phase can be more important if each of them is completely necessary? Well, except for Diagnostic phase.

The thing is, this phase is not completely necessary; strictly speaking, it doesn’t even belong to implementation. It comes before—it is a part of project sales cycle. You do it, or you don’t do it. However, doing it can have a profound impact on the flow and outcome of an implementation project. Therefore, I dare say it’s more important than other phases, because it has a tremendous potential to tell you up front what you can expect from the implementation if you go into it.

Old Sure Step used a short pre-analysis phase, also called Diagnostic, which focused on making a high-level analysis of fits and gaps between customer’s requirements and product’s features, and on delivering an implementation proposal. The most important deliverable of this phase was the proposal, but how exactly this proposal was created, or how the figures were estimated, was more of philosophy than mathematics. Unfortunately, philosophy is bad at explaining costs, benefits and ROI; mathematics is extremely good at it. Somehow I figure the trust levels of mathematics appeal much better to CxO tastes.

In new Microsoft Dynamics Sure Step (“2.0″ – it really isn’t a versioned product, and this isn’t the official designation) the Diagnostic phase makes a true step ahead of old Sure Step by taking a more exact, almost mathematical approach to project costs, benefits and risks estimations, by offering a set of tools that you can use to evaluate current customer’s situation, provide guidance about project approach, confidently analyze the major risk factors in measurable terms, provide a cost/benefit and ROI overview, or even make a proof of concept which can argue a case for a specific Microsoft Dynamics family product.

This set of tools is what distinguishes Sure Step from other methodologies, and they are called decision accelerators.

I’ve been involved with projects where sales cycle took more than a year, not counting the RFI and RFP phases. It’s not that majority projects look like this, sometimes decision is made in a snap (an equally bad situation), but sometimes the sales cycle takes an enormously long period of time to complete simply because the customer is indecisive. And when the customer is indecisive it is typically because of this: they haven’t been given a compelling reason to choose a product (or dismiss it). If diagnostic phase focused only on doing a high-level analysis of business processes and prepare a proposal, the customer didn’t have enough confirmation that the investment will be a sound one. How risky the implementation will be and what are the major risks? Is this the right product for me? Will this product really be able to cope with my requirements? How difficult, and costly, will it be to upgrade to a future version? Will my investment into this version lower or raise the costs of maintenance and upgrade? When does my investment break even, and when do I start to get return on it? These questions are crucial—if you get an unsatisfactory answer to any of these, are you willing to proceed? Yet, most of these questions largely remained unanswered. Not anymore.

The decision accelerators are provided as a set of packaged activities that can be performed in fairly short time (if you ask how short, I can’t tell you: it’s the same as asking a car salesman how much a car costs—it depends). But the decision accelerators are not there only to help the implementing partner to understand their customer’s business and prepare a proposal, but primarily so that they can show to the customer what the implementation will look like, and provide compelling argumentation for, or against the implementation itself. They can provide answers to the questions above, which previously faced a decent chance of remaining unanswered before analysis started.

The true value of these decision accelerators from implementing partner’s perspective is that they are not just a mere set of methods that explain the steps—yes, that’s inside too—but they come with tools that help calculate the necessary metrics, and make preparation, planning, execution and wrap-up activities smoother, more predictable, repeatable and efficient. This makes for an extremely swift and smooth diagnostic phase, and gives both the customer and the partner enough information to make a decision and to prepare for the upcoming project. I believe that Sure Step Diagnostic phase offerings won’t leave any customer with unanswered questions, and reluctance to either go into the project, or to dismiss it altogether, will be much less common.

Have you considered a career in Microsoft Dynamics? Yes, I know, many of you have are most likely already happily employed by a Microsoft partner company specializing in Microsoft Dynamics solutions. Good.

On the other hand, there is probably plenty of you out there considering starting a career, but locating highly specific jobs in Microsoft Dynamics posted at general purpose job boards can be difficult. How many Microsoft Dynamics NAV positions are posted on Monster.com? Really, how many? How many of these are relevant? Yes, these positions have something to do with NAV, but if you are looking a job as a Microsoft Dynamics NAV consultant, much of what you can find there is noise, such as all those accounting positions looking for experience in using Microsoft Dynamics NAV. Meh!

The truth is, specialized job boards have always been better of landing a perfect job opportunity to you. Just recently MSDynamicsWorld.com has started a new specialized job board for relevant Microsoft Dynamics positions. Go check it here: MSDynamicsWorld.com Job Board.

Okay, they have just started, so at the time of writing this post there are not that many openings posted, but I believe they will grow pretty soon. If for nothing, for one great feature that I don’t remember seeing anywhere: RSS subscription! Yes, you can subscribe to your filtered seach using RSS and get relevant job postings right into your favorite reader. Other job boards typically send you mail, and in the era of spam ubiquity, RSS does a far better job at getting through to you. A splendid idea, and a real move ahead of mediocrity so common nowadays.

It is not the only specialized Microsoft Dynamics job board out there, but they are new, and they deserve some attention and traffic to get growing. Do them a favor, and check it out.

Methodology is a tough topic. There are good methodologies, there are bad methodologies, there are good methodologies gone bad. Methodology is not a silver bullet, it won’t just make any problems disappear, and is hardly ever the single source of success or failure. But a methodology can be a major contributor to success. I could put it this way: you stand much better chances of success if you apply a methodology, then if you don’t. With something as critical as an implementation of business software, methodology is a key success factor. According to Jim Johnson of Standish Group, it’s number nine on their ten identified most important success factors.

These are all the success factors, according to Standish Group:

1. User Involvement
2. Executive Management Support
3. Clear Business Objectives
4. Optimizing Scope
5. Agile Process
6. Project Manager Expertise
7. Financial Management
8. Skilled Resources
9. Formal Methodology
10. Standard Tools and Infrastructure

There are two topics that have been tickling my imagination recently: Sure Step (especially what’s unofficially known as Sure Step 2.0) and its value, and achieving capability maturity (as in CMM) within a Microsoft Dynamics NAV consultancy. What is my top concern at this point is how to achieve higher CMM levels with Sure Step. I am currently attending a Sure Step training, and the more I am getting into it, the more I am sure that significant improvement to implementation processes can be done with Sure Step as-is, and that Sure Step can also be used as a tool which can lift the consultancy organization’s maturity at least a level or two (with majority of consultancies I’ve seen still firmly on the ground level 1, or struggling to get to level 2).

Why do I think that Sure Step can be used to achieve this? Well, a major premise of the whole concept of CMM and CMMI are that they will increase the productivity, quality and customer satisfaction. Ok, so far we are aligned with the Sure Step – you can use Sure Step to achieve these as well: productivity because you don’t have to start from scratch—tools and templates are in place already, you just need to reach for them; quality because Sure Step helps you achieve higher repeatability (this alone will get you to CMM level 2), and repeatability can drive quality through insight which leads to continuous improvement; and customer satisfaction, because with applying Sure Step you dramatically increase chances of project success (not of project closure – a project to be a success you need to do more than merely close it).

If we take a look at top ten success factors, according to Standish Group, this is how I see Sure Step fits into that picture:

User Involvement and Executive Management Support

Methodology alone won’t bring these two in, because it’s mostly up to the customer to provide them. However, Sure Step provides clear guidance about user involvement and the roles the customer’s people need to play in the process. Furthermore, it makes these things clear up front, before the project starts, which makes for a much better resource planning from the customer side. In my experience, when user involvement was missing in the project, it was not because they couldn’t be made available, but because their involvement wasn’t planned. Consultancy plans their own resources: consultants, developers, architects, etc. but customer is left to their own, and their involvement is usually ad-hoc on an as-needed basis: when we need to involve you, we’ll let you know. Sure Step addresses this issue by exactly specifying who needs to be involved and when: this allows for a precise resource planning, and if customers are made ready in advance enough, it will be more easier for them to dedicate the necessary people to participate in project activities.

Another problem of poor user involvement is having wrong people in wrong places. Without clear resource plans, people are assigned based on their ad-hoc availability, not based on their skill sets or experience. I don’t need to explain what effect this has on motivation, and contribution to project. Sure Step goes as far as defining the exact kinds of skills, preferable experience and knowledge levels of all project participants, which makes it much easier to see whether it makes sense or not to send a certain person, and not the other one, to participate in a requirements gathering workshop, a testing activity or a training.

Regarding executive support, Sure Step doesn’t (and can’t) help too much to get the executives involved if they don’t want to. However, with properly conducted Diagnostics phase or Sure Step, the project costs and benefits will be much more specific, and ROI better articulated—with proper project status communication towards project sponsors, which is covered by Sure Step, executives are better informed and more involved, the project has higher executive visibility, which gives you much better chances at getting more executive support as well.

Clear Business Objectives

Sure Step directly addresses it within Diagnostic phase with Scoping Assessment and Business Case decision accelerators. By preparing a good scope statement and a business case and a project charter, business objectives will be clearly defined, and it will be much easier to validate alignment of specific requirements and change requests against these objectives.

Optimizing Scope

Among major reasons why scope creeps happen is low or no insight in the costs the changes bring. Changes are inevitable, and changes are good, but unmanaged changes are disastrous. Sure Step addresses scope management since early diagnostic phases, throughout the Analysis phase, through Requirements and Configuration cross-phase process, and through Scope Management project management discipline.

Agile process

Well, honestly, I think that agility is not the strongest point of Sure Step, because Sure Step exhibits more features of a waterfall process than of an agile process. But in my opinion, this is actually an advantage. When Standish Group identified Agile Process as a success driver, they have been analyzing all kinds of software projects. There is a huge difference between implementing Microsoft Dynamics NAV and developing a new product from scratch. Software development is (or at least it should always be) a smaller part of a Microsoft Dynamics implementation project (except probably for CRM projects which can include extensive developments). Microsoft Dynamics NAV is not a development platform, it is a finished product—approaching it as a development project can do a lot of harm. Why do I believe so? Primarily because of regression issues. When you develop something from scratch, early change requests have little impact on already developed features, causing little regression in the process. With NAV even small changes can cause terrible regression issues. Yes, you can change anything with NAV, but it doesn’t mean you have to. I see a phased approach such as Sure Step a much better fit for Microsoft Dynamics products implementation projects, than an agile approach. Again, CRM might be an exception, because it truly is a platform, but I am not blogging on CRM, so I rest my case about agile processes here.

Project Management Expertise

This is not a methodology issue, and no methodology can bring you expertise.

Financial Management

This is really part of standard project management tasks, mostly covered within Cost Management discipline of project management, and a part of Sure Step as such. However, Sure Step also has Proposal Management cross phase process which directly addresses management of the project’s finances.

Skilled Resources

Similar to Project Management Expertise, this is also something that doesn’t come packaged into any methodology out there. However, Sure Step does an excellent job explaining the project roles, and their preferred and expected skills. With this, you can do a much better job at matching right people with right responsibilities, thus increasing your chances of a project success.

Formal Methodology

Obviously, Sure Step is a formal methodology, so the point is made automatically.

Standard Tools and Infrastructure

Conveniently, this one comes right after the methodology. In fact, Sure Step is not only methodology, as in a-set-of-prescribed-methods kind of methodology. Sure Step includes much more than just the guidelines: it contains tools and complete document templates, most of which can be used out of the box. Sure Step also allows customization of these tools (even encourages it), to fit your specific needs, or to integrate it with your own experience, methods, tools and templates.

So, in my humble opinion, Sure Step does an outstanding job at introducing most of major success factors, or helping you introduce them. I tried to show how, but I’d also like to hear you voice out your opinion, or share the experience.

Hint: this is a post for developers, and mostly junior developers, those who are still learning how to code properly. I know, I promised not to blog about stuff like this, but I simply couldn’t help this time.

A friend of mine has asked me for help.

“There is this C/AL function I had to rewrite, now I end up with 106 BEGINs, and only 105 ENDs. Do you have any idea how to find where this missing END belongs?”

No, J., I’m sorry, I don’t. I feel your pain, though. This reminds me once again of legendary “whenever you are writing code, write it as if someone else will have to maintain it and their last name is Gotti, and they know your home address” quotation I already quoted once. I am sorry, J., that you ended up maintaining this piece of, well, code (yes, it still qualifies as such).

“It’s a single function of an add-on, which grew organically over the past five years…”

No, it didn’t grow organically. It metastasized.

While a lot of code gets to grow over time, especially with add-on modules which go through several iterations of releases for many different customers, it is not the excuse to write bad code. There are a few lessons about coding we can all learn from J.’s unfortunate experience of maintaining other people’s code:

1. Don’t just code away: think instead, and think first. Think about what you need to accomplish now, and what you might need to accomplish tomorrow. The sooner you start coding, the later you finish.

2. Abstract whenever possible: Abstraction is when you take a coherent piece of code and blackbox it away in a separate function. Then you call this function from wherever you took the code in the first place. This makes your code more readable and much more reusable (not as in copy/paste, which is how a lot of code gets reused, unfortunately) – you can call this function from other places as well, reducing the overall code length and improving understanding.

Look at this:

OnRun()
CustLedgEntry.SETRANGE(“Customer No.”,SalesHeader.”Sell-to Customer No.”);
IF CustLedgEntry.FINDSET(FALSE,FALSE) THEN REPEAT
  CustEntryApply.RUN(CustLedgEntry);
UNTIL CustLedgEntry.NEXT = 0;CustLedgEntry.SETRANGE(“Customer No.”,SalesHeader.”Bill-to Customer No.”);
IF CustLedgEntry.FINDSET(FALSE,FALSE) THEN REPEAT
  CustEntryApply.RUN(CustLedgEntry)
UNTIL CustLedgEntry.NEXT = 0;

Replace it with:

OnRun()
ApplyEntries(SalesHeader.”Sell-to Customer No.”);
ApplyEntries(SalesHeader.”Bill-to Customer No.”);ApplyEntries(CustNo : Code[20])
CustLedgEntry.SETRANGE(“Customer No.”,CustNo);
IF CustLedgEntry.FINDSET(FALSE,FALSE) THEN REPEAT
  CustEntryApply.RUN(CustLedgEntry);
UNTIL CustLedgEntry.NEXT = 0;

Generally, this is better. And you can do an awful lot of these with just about anything. This was an innocent example, where four lines of code were basically copied and pasted. The more lines of code you abstract, the more you benefit in the future.

When to abstract? It’s hard to tell, really. It depends. But no matter what, always abstract OnPush trigger logic. Anything that has even a remote chance of being called from two separate places is a good candidate. If you catch yourself copying a piece of code and pasting it elsewhere, stop right there, mane an abstracted function, then call it from both places. I’ve recently worked on a project where I found exactly the same piece of code handling some custom entry table in exactly 73 objects. The only difference was that some filters were different. You’d be surprised – this wasn’t written by a rookie in the first place. The guy was a seasoned developer, who just thought he didn’t have enough time to do the abstraction in the first place, and didn’t think this would get copied to so many different places. Don’t let this happen to you. And check point #1, it applies here as well.

3. Don’t IF THEN ELSE IF THEN ELSE BEGIN END ELSE IF THEN ELSE: When code grows, it often does so because a case which wasn’t supported initially now has to be supported. Don’t just add another IF to solve the problem. IFs, especially the nested ones, are hard to follow and hard to understand, and can be a hatchery of bugs if your logic needs exclusivity. This can lead to trouble:

IF i = 1 THEN
  DoSomething(i);
IF i = 2 THEN
  DoSomethingElse(i);
IF i = 3 THEN
  DoSomethingCompletelyDifferent(i);

If you start with i = 1, can you tell for sure that the other two cases won’t fire? No. So you do this:

IF i = 1 THEN
  DoSomething(i)
ELSE
  IF i = 2 THEN
    DoSomethingElse(i)
  ELSE
    IF i = 3 THEN
      DoSomethingCompletelyDifferent(i);

Ohmy, here we go… imagine adding some more logic in the future and you can see where this gets to. CASE does a much better job, so why not start writing your code immediately with CASE if you expect there might be a branching in the future?

This is so much easier to follow:

CASE i OF
  1:
    DoSomething(i);
  2:
    DoSomethingElse(i);
  3:
    DoSomethingCompletelyDifferent(i);
END;

Okay, this was too obvious. But there is a splendid trick with CASE:

CASE TRUE OF
  i = 1:
    DoSomething(i);
  i = 2:
    DoSomethingElse(i);
  i = 3:
    DoSomethingCompletelyDifferent(i);
END;

Now if a fourth case arises, which should fire only if other three haven’t, but has nothing to do with variable i, then you can simply add it here and retain an easy to follow code:

CASE TRUE OF
  i = 1:
    DoSomething(i);
  i = 2:
    DoSomethingElse(i);
  i = 3:
    DoSomethingCompletelyDifferent(i);
  j = 2:
    DoAnotherSomething(j);
END;

Much, much more readable (and maintainable) than:

IF i = 1 THEN
  DoSomething(i)
ELSE
  IF i = 2 THEN
    DoSomethingElse(i)
  ELSE
    IF i = 3 THEN
      DoSomethingCompletelyDifferent(i)
    ELSE
      IF j = 2 THEN
        DoAnotherSomething(j);

4. Don’t have 106 BEGINs and ENDs within a single function. It’s not to say that a code can’t branch 105 times, of course it can (albeit not too often). It’s simply to say that in case you have 106 blocks of code, you are better off applying any of the rules above, you’ll end up with less blocks of much more maintainable and repeatable code. I bet that any time that you have 106 blocks of code (or 20 blocks of code for that matter), there are many candidates for code reuse, abstraction, better structuring or a combination of these.

There are probably many more lessons to learn from things like this, and if you have similar experience, or similar C/AL (or general) coding advice, please share!

[Updated]
I had to update this post a little bit, see below for the details, but the killer feature had to go
[/Updated]

Remeber that tool “Automated Version Management” that I published here and on Mibuso five months ago? It has just got an update: version 2.0.

First, a disclaimer: THIS IS PROVIDED AS IS, WITHOUT ANY WARRANTIES, AND YOU USE THIS AT YOUR OWN RESPONSIBILITY. All other disclaimers here on this site apply as well. Now that we are over with legal yadda-yadda, let’s get down to facts.

What’s new? A lot.

1. Initialization: Before you can use the tool, you must call Initialize Version Management function, which makes a default version out of each object.
2. Check In / Check Out functionality: Objects can’t be modified by any user, unless that user has first checked out the object. If an object is checked out, only the user who has checked it out can save it. Other users can’t save it. New objects can be created at any time, but for any consecutive changes, you must check out the object first. You must check objects out for deletions, as well as for restoring previous versions.
3. Cancel Check Out: Object which has been checked out can be reverted to the last checked-in state by simply calling Cancel Check Out. Any saved changes will be rolled back.
4. And a big fat cherry on top: For a true collaborative development, an extra feature is there – a user who has checked out an object can save it as many time as they want – it won’t affect other users until the object is checked in. For example, Johnny checks out Codeunit 80, and starts making changes. Any changes that Johnny does, will be visible only to him. If Jenny looks at Codeunit 80, she will se the latest checked in version. Only after Johnny checks in the Codeunit 80, Jenny will see the changes made by Johnny. Ok, this doesn’t work with tables – have to figure out how to handle tables the best possible way, but with other objects, it works ok.

[Update] Unfortunately, I had to drop this last feature, because it simply can’t be made to work with tables. Any table change subsequent to the initial table creation would simply not update the underlying SQL Server table object, so I had to change this and upload the updated version – it has everything, but this.[/Update]

Ok, for this last gimmick I had to do some ugly hacks to the database: rename the Object table to Object (NAV), then create a view called Object over the Object (NAV) table. This view selects the latest modified version for the user who checked the object out, and checked in version for all other users. There is a bunch of INSTEAD OF triggers over this view to make this possible. Now – I can’t tell whether this will work in 100% of situations, so before you decide to do anything with this – check it first, on an empty Cronus database. It worked for me, without any problems, on two different databases. NEVER EVER USE THIS IN ANY PRODUCTION ENVIRONMENT.

Of course, all functionality from previous versions, such as the possibility to restore a previous version, is still there. Also, thanks to suggestions from many users, the tool now correctly displays user name. I also had a suggestion to implement the Restore As functionality, but this would require some more tricks with SQL Server, it will come in a future version.

To install this tool, simply download the [Update]Version Management 2.01 file, rename it from .doc to .zip [/Update] (unfortunately, WordPress doesn’t allow me to upload anything else), it contains all the files embedded. Then first import the objects into NAV, then execute the SQL script in the context of the database which you want to have version managed.

If you have any questions, please feel free to ask them here, I’ll be happy to answer. Also, if you find any bugs, let me know!

I’ve just got a call for help from a partner, about their customer who has decided to move from basic inventory management to full-scale warehouse management system. The question was how to post the opening balances for existing inventory quantities in flat locations to warehouse-managed ones.

I thought this might deserve a quick blog post, you can never know when someone else would want to do the same thing.

There are basically two ways how you can achieve this:

1. Transfer Orders: you go and create a transfer order which transfers all inventory from old (non warehouse managed) locations to new (warehouse managed) ones. You post the shipment from old location, then create and post the warehouse receipt for the new location.
2. Journals: you post the negative adjustment of closing inventory balance in old locations using Item Journal, then post the positive adjustment of opening inventory balance in new locations using Whse. Item Journal.

There are advantages and drawbacks of both approaches.

With Transfer Orders you’ll have more Item Ledger Entries and Value Entries (and G/L Entries, of course) than you would want to, because there is an In-Transit location involved. However, you keep the value link, which means that any cost adjustments on original entries will propagate all the way through (to receipt entries to start with, and any consecutive entries for any outbound transactions in the future).

With Journals, you get less entries, which means easier tracking. However you lose the value link, which means that any cost adjustments on original entries won’t propagate further, and you will have to revaluate all the opening balances manually to reflect the change in value.

In any case, I am not a Warehouse Management expert, and I believe there may be other ways, or better ways, or other pro’s and con’s of these two approaches. I would personally always opt for the first choice – Transfer Orders.

If you have a better idea, or a cleaner solution, please share it with all of us here.

This post has no category. It may be irrelevant to you; it won’t provide any value to you or your business.

But to me, personally, it’s the most relevant so far.

This is a tribute to a man who changed my life, who is responsible for much of what I am today. He was a mentor to me, and taught me how to fish, when everybody else was feeding me fish, or even keeping all the fish selfishly for themselves. He showed me the how, and the why of Microsoft Dynamics NAV, and always believed in me, even when I was losing faith. He was challenging me, drawing the best out of me, and pushing me further every minute we spent together. Together, we became a team; we built things together. He was a true friend, always had time to listen and to share, and share he did. I miss our time.

R., Happy Birthday!

A few days back, while prototyping a new solution for a customer, one of the key users said: “But in our old software it didn’t work like that.” I was about to try to explain why the change, but then the user’s boss said:

- We aren’t implementing a new solution so that everything can stay the way it was.

How often does it happen to you that your customers say to you a similar thing: “But in our old system…”? What do you say to them? How do you approach change when your consultant proposes a new way of doing things, or a new approach to a common problem?

Any new software implementation will bring many new changes. Yes, user interface will change, functions will change, but these are the least important. Many times, more often than not in fact, you will have to change the way you do things. When the software is inflexible, and you can’t customize it to your wishes, you’ll just accept this as a given, and the change will take place. But if the software is flexible, and you can customize it to your fancies, you’ll try to bend it to meet your needs, and you’ll try to get your new solution look like your old one. And this happens more often than most customers would be willing to admit. And it’s natural.

But it doesn’t mean the software must be bent. Before you decide to mold your new software to the likeness of your old one, try as much as you can to see the benefit of the new ways of doing common tasks. It’ll usually pay off.