ERP Ideas Blog

Posted by Gretchen Freeman-Cromar on January 5, 2012

Important note: The Sith Lord Darth Vader is actually a fictional character from the Star Wars saga. He was not real. Still, his character clearly showed brilliance for project management. And now, for your entertainment, the Top 10 Reason’s Darth Vader Was a Great Project Manager:

Number 10: Vader prioritized brutally. Vader paid close attention to the happenings of the galaxy, evaluated the impacts of any given issue, and went after the highest priorities…time after time. No emotional attachments, no personal agendas…just the right thing to do to preserve the Imperium, and see his project through to successful completion. In project management, if you can’t prioritize, you won’t get anything done, let alone anything done well.

Number 9: Vader made decisions based on objective data, not whims. Vader consistently evaluated the performance of his team, and made changes to fix problems when the team didn’t perform. Sure, there may have been some fear and terror, but put all that aside. Project teams needs to feel safe and supported, but they also need to know that the project goals need to get met, and if you aren’t delivering on your commitments, changes need to get made.

Number 8: Vader made commitments, and worked hard to keep them. I mean, how did he manage to get that second Death Star operational so quickly anyway? Hard work, that’s how. Vader understood the importance of commitments, and more importantly, the significance of fulfilling them. Trust in teams is built on commitments.

Number 7: Vader took time to recharge, relax, and get some perspective. Everyone on the team is motivated to solve the problem, and get to done. Conflict is inevitable in that kind of environment, and a good project manager needs to get in there and confront those issues head-on. Of course, this can be exhausting, emotionally and intellectually. Vader understood this, and was careful to take time out of his busy project schedule to relax, meditate, and gain some perspective. Vader managed risk and expectations…pre-emptively. Remember that time when Darth Vader went to Cloud City, bought off the management, then lured Han, Leia, and Chewbacca into a trap? Genius. The amount of planning and forethought that went in to that little exercise must have been epic. Good project managers think about their projects defensively, and act to protect them aggressively.

Number 6: Vader managed risk and expectations…pre‐emptively. Remember that time when Darth Vader went to Cloud City, bought off the management, then lured Han, Leia, and Chewbacca into a trap? Genius. The amount of planning and forethought that went in to that little exercise must have been epic. Good project managers think about their projects defensively, and act to protect them aggressively.

Number 5: Such a persuasive fellow. Of all Vader’s substantial capabilities, perhaps his most effective one was his ability to persuade people to do what he needed done. With the exception of his own kids (in his defense, have you ever tried to get your kids to do something?), he did a pretty great job of getting people to cooperate (whether through fear, obligation, or The Force!).

Number 4: Vader picked a methodology and stuck with it…until it didn’t work. Everyone knows that Vader betrayed his Emperor to save Luke from certain death upon Luke’s refusal to join the team in a certain role. Vader saw that his previous methods of fear and intimidation didn’t seem to work with Luke, or any of the rebels any longer. Boom! Change of tactics to get the job done.

Number 3: No problem is too big to tackle. Sure, Vader had an enormous skepticism that served him well in managing risk. All good project managers need that ability. But good project managers also have to be optimistic enough to push through tough challenges and look for solutions, however improbable their success. Vader’s optimism and confidence in his team’s ability to overcome all obstacles is an excellent lesson in persistence.

Number 2: It is never too late to do the right thing. One of the most profound moments in Vader’s career came when he took responsibility for all the morally wrong things he did, and did the right thing. Good project managers will take the time to reflect on their choices, and re-make the choices they don’t feel good about. The right thing is crucial to trust on a team, even if the right thing is a hard thing.

Number 1:  Vader was never afraid of getting his hands dirty. He made sure he had a clear understanding and appreciation for the hard things that his team had to execute on. This, I think, is what made Vader better than just good. He got involved in the work of the project, and his team followed him because they knew he understood and was invested in the project’s success!

Take a moment to watch this one minute video clip — I’m sure you’ll appreciate Vader’s excellent PM skills getting the project back on track! Note: He had great support from his management team — the Emperor — which helped.

I’m sure we all agree Vader wasn’t a perfect project manager. He lacked charisma, empathy and his people skills were somewhat questionable. Additionally, he wasn’t infallible. For example, there was no back-up plan to account for losing shields on the second Death Star, and it let the reactor core completely vulnerable. Lastly, Darth didn’t think they would have any trouble from a small band of rebels and some fuzzy, little Ewoks. Where was the local back-up system to protect the reactor core? Let’s take an important lesson from Darth Vader: When managing a project or writing code, don’t forget to account for Ewoks!

Excepted from Brandon Koeller’s “Top 10 reasons why Darth Vader was an amazing project manager.”

Posted by David on January 5, 2012

As a Microsoft Dynamics NAV Developer we are aware, NAV is a highly customizable solution and while this is certainly an attractive attribute, it does imply a certain level of responsibility at the partner level. When we customize objects and/or code we are creating a de facto system behavior or functionality; a situation whereby events will play out in the business logic accordingly and without human interaction, input, or control. In many cases this is necessary and desired but it is important to consider that there may be alternative approaches.

To add some context let’s first recognize that there are a few options when it comes to changing the behavior and user experience of NAV; Personalization, Configuration, and Customization. Listed in this order they represent the preferred approach or hierarchy when it comes to system change.

Personalization

With Personalization, end users can add, remove, or arrange UI components and controls to best suit their individual work space preferences. Personalization allows simplified change but it is a powerful mechanism because it allows individuality within the overall solution and can be administered by the end user.

Configuration

Configuration is in my opinion the most versatile as it allows for expanded system functionality to be enabled (and in some cases, disabled) as desired. Normally configuration is thought of as having a system-wide impact but it can also parallel personalization; we see examples of this when considering business logic that is conditioned on a value in the User Setup table. Regardless of the scope of impact, the true versatility and power of configuration is recognized when it is coupled with customization.

Customization

Customization coupled with configuration adds a certain element of intelligence to our solutions through the use of global setup flags and/or the existence of certain data elements to steer their behavior. This relationship is especially important when we apply it in the context of an ISV product. As enhancements continue to grow such a product we must be thoughtful about how we position them within the overall solution because not all enhancements apply to all of our customers all of the time. The proper positioning of our enhancements will result in a product that is both powerful and flexible. What’s more is that we will have enabled the administration of this power and flexibility to occur at the customer level.

It is important to recognize the hierarchy of change and apply our resolution at the lowest level first. This is true whether we are troubleshooting a specific issue or developing an enhancement. It is easy to jump straight to the code base first to address an issue and miss out on the fact that we could handle the issue at a lower level. In the end we must not lose sight of the idea that the simplest solution is many times the best solution.

Posted by Connie on December 12, 2011

Q: How do I move to the next field in NAV 2009?
A: The RIGHT ARROW key will move to the next field or character in NAV 2009.

Want more shortcuts? Check out all the NAV 2009 Keyboard shortcuts.

Posted by Connie on December 8, 2011

Q: Is there a shortcut to move between to the next frame or tab in NAV 2009?
A: Yes! CTRL + PAGE DOWN is the shortcut to move to the next frame or tab in NAV 2009.

Shortcuts make everything easier don’t they? Note: The same shortcut works in Ceres 2009.

Thanks to Janice at North Texas Food Bank for submitting this NAV 2009 tip request.

Posted by Kimarie Wolf on November 22, 2011

It’s that time of year again. Sales is pushing to close last minute deals, production is gearing up for the holiday runs. In accounting it’s all about crossing the “t”s and dotting the “i”s. Making sure everyone follows the processes and paperwork. The question is….

Are you prepared for your year end auditors? Take our quick poll and see how you stack up.

Posted by Gretchen Freeman-Cromar on November 9, 2011

Below is a great article from the October PMI eNews with great advice on how to overcome the issues involved in estimating projects.

What Causes Bad Estimates…and What You Can Do About It

by James T. Brown, PhD, PE, PMPi

Estimates are not created by machines. They are made by people with human foibles. Politics, pressure and optimism all come into play when it comes to estimating.

A study of 258 projects in 20 countries tallied an amazing nine out of 10 with cost overruns. Budget estimates can be off‐target by 100 percent or more, according to the Oxford Review of Economic Policy.

Two factors are major contributors to inaccurate project estimates. Factor one is insufficient time to deal with uncertainty in the estimating process. Factor two is the need of certain sponsors to create artificially low estimates in order to get a project initiated. Managing expectations and clear communications are a project manager’s keys to success.

Acknowledge Uncertainties

Project managers are very good at estimating…when they know about what they are estimating. But as you would expect, estimating when there is a lack of knowledge is problematic.

Time pressure can compromise the quality of estimates. Additionally, gathering estimating information can cost money, because it can involve everything from research and hiring consultants to prototyping.

When there is uncertainty, a logical course of Acton is to increase the estimate to deal with that uncertainty. Getting leaders to accept a larger estimate to account for uncertainty is where the challenge lies. Unlike project managers, stakeholders often do not look at the entre puzzle — they look for the piece that fits within their constraints. Sometimes they apply pressure to make the estimate fit.

Often leaders prefer to proceed with an optimistic number. From my experience, I have found that it is best to communicate the worst-case estimate first and then work from there.

To manage estimate expectations effectively, take every opportunity to communicate the uncertainty and assumptions associated with the estimate throughout the life cycle of the project. Try not to discuss the estimate without referencing these assumptions.

Stakeholders may acknowledge this uncertainty at the beginning. Once a number is in place and the project starts, they tend to forget the assumptions and uncertainty associated with the original estimate.

It is your job to always keep this information front‐of‐mind. Assertively communicate when an assumption proves to be invalid or there is a change in a factor that affects the uncertainty associated with an estimate.

Deal with the Pressures to Underestimate

What sells a project and what it costs to create the project deliverable can be two different things.

In my experience sponsors some‐times make the decision that the project is necessary but know it would never be approved by the organization or stakeholders at the project’s realistic cost. They then make a calculated decision for a lower project estimate.

Yes, most everyone knows it costs more — but it cannot be sold at that price, so the estimate for the project is essentially a political decision. Once approved, the project becomes difficult to kill because of what has been invested.

Although this can be a common situation, it is always contextually a complex one. Further, it forces the project manager to deal with unrealistic limits that have been placed on your estimates.

I believe in dealing with this kind of situation it is best to maintain your integrity and gracefully communicate what it really takes to make the project successful, so that decisions are made with the facts available. The decision might still be a political one that may put you and your project in a difficult position, but at least you have communicated all the facts.

Ideally, you would have time to generate the most accurate estimates possible and not be pressured to make the estimate conform to a target number of questionable origin.

In the real world, time pressure and target numbers are a fact of life as evidenced by the Oxford Study that showed nine out of 10 projects with overruns. Equally if not more important than how you estimate is managing stakeholders’ expectations throughout the project life cycle with regards to that estimate. Managing expectations is the human side of the estimating equation.

Posted by Jody Leoni on October 26, 2011

Here’s an interesting article with great perspective on project estimating from the Project Management Institute, PM Network Magazine.

The world of project management doesn’t seem like it would often overlap with theology (other than the occasional realization that only divine intervention could bring in certain projects on-time and on- budget).  However, the seven deadly sins are remarkably applicable to project estimating. Take a look!

#1. Greed

This sin normally applies to material wealth, but people can also hoard information and time. Greed and fear are often related. With estimating, the questions often asked are, “Why are you asking me for my data?” “Do you know how busy I am?”  Sometimes team members do not feel they have the time to spare to share data and past experiences, and when this happens, ultimately the estimates suffer. Charitable teamwork by everyone helps us come up with numbers based on our shared experience and internal tools, rather than guesswork.

#2. Gluttony

As project managers and development estimators, we’ve often seen others add contingency costs to project estimates in lieu of doing the real work upfront to produce an accurate estimate.  The problem with this is that when this is handed up to the overall project manager, chances are another few contingency cost points will be added.  The end result is a bloated estimate.  This sin just adds good hours on top of bad hours. The message is don’t pad your estimates; do the work up front.

#3. Sloth

Rather than using good tools, methods and models backed up by historical data, correct training and documentation, lazy estimates are too often the norm. Don’t just guess.   These estimates relate to project costs as well as timelines, when we actually need things to be completed. We have all heard the lazy client say “I need it ASAP!”  or heard a project manager say “We really need to have it by November 1^st. I don’t care what you have to do.” Arbitrary dates and guestimates for costs are too arbitrary, and impossible to manage to when everyone knows they are not accurate to begin with. The message is put in the time to maintain realistic dates from clients and put together realistic estimates on hours to deliver.

#4. Wrath

One of the benefits of a diligent estimating model is that it takes much of the emotional sound and fury out of conversations with clients and with management. Construction of accurate models is a journey, requiring patient, continuous improvement over time.  No one likes to call the client with budget and timeline misses, or similar calls with management, so up-front work pays dividends.

#5. Envy

If you have seen a better process someplace else, bring it up! Do not sit back and wish we did things that way. No one wants to work in a failing system if you’ve seen it work someplace else differently and with better results, then share!  We want your feedback and are open to process-improvement planning. We incorporated much of what we do from the direct experience from our team members.  Don’t envy the old ways, bring new ideas up and help us all to improve.

#6. Pride

When it becomes clear we cannot meet a goal we have committed to, sometimes we shift our commitment to a target we are able to reach. Rather than be up-front about our ineffectiveness and use our metrics as an opportunity to improve, we re-baseline to make ourselves look good. At the end of each year, we are able to say we had made 90 percent of our targets, but these are misleading measurements because we are only looking at things from our point of view and not our customers! If our estimates are off, don’t be too proud to talk with the customer  to push the timeline or re-visit the budget. Move over pride, make room for humility!

#7. Lust

You ever know a customer or project manager who wants what they want when they want it, no matter what? Inflexibility on delivery can come with its share of problems. Insisting a team meet every delivery deadline without exception and by exclusively tying success to meeting schedules  will lead to a team shipping a product on time – no matter how low its quality is.  What’s wrong with that? Industry data show that we can stamp out bugs for as little as US$60 each if caught early in the process. Once in the field, we have spent as much as US$15,000 to fix a single defect.

So gang, like most people, sometimes we are sinners. Sometimes we are saints. In both roles, we’ve learned that a good estimate leads to better success in everything we do.

Posted by Gretchen Freeman-Cromar on October 13, 2011

The most significant change to the ERP landscape we are facing is ‘the Cloud.’

Here are answers to the three most commonly asked questions:

• Why (should I consider the cloud)
• What (is the cloud opportunity)
• When (to use cloud)

Why Should I Consider the Cloud?

Microsoft Dynamics ERP Cloud solutions are intended to give customers CONTROL through visibility into their businesses, which could enable them to make smart decisions that IMPACT THEIR MARGINS and improve cash flow—ultimately driving business GROWTH.

GAIN CONTROL: Multiple insights into business performance, including mobility

INCREASE MARGINS: Shift from capital expense to annuitized operating expense

DRIVE GROWTH: Maximum server capacity is always available and the system offers flexibility & scalability that allows for growth.

What is the Cloud Opportunity?

The ERP market is shifting to the cloud. Here’s ‘what about the cloud’ that is manifesting this market change:

• Small and midsize business (SMB) prospects (10–250 PCs) and midmarket prospects (251–2,500 PCs) who are evaluating Microsoft Dynamics ERP want to realize the benefits at a decreased initial cost and minimal startup effort (“turn on & go”).
• Prospects who are seeking to consume enterprise resource planning (ERP) technology as a utility against their monthly operating budgets, which could allow them to reserve their IT capital budgets for other revenue-generating activities.
• Prospects who are interested in reducing or outsourcing their IT infrastructure to avoid the standard IT procurement process, eliminate the cost and effort of implementing regular data backups and software updates, and reduce large infrastructure investments.
• Prospects who need the flexibility to add users or locations quickly and easily.

When is the Cloud Best Utilitized?

Microsoft Dynamics ERP cloud-based solutions should be the first choice for organizations with the following characteristics:

1. Lack the hardware needed to upgrade
2. Lapsed fees that are insurmountable
3. Need to expand the user base and/or functionality, but have limited budgets
4. Limited or reduced IT staff
5. Compliance issues and multiple locations—need to get to one solution
6. Ease-of-use and quick ramp-up are top priorities
7. Have exhibited rapid growth

Stay tuned next month when I will answer the next three most commonly asked questions:

• Why should I select Microsoft ERP cloud-based solutions?
• What makes Microsoft different from its competitors?
• How do I handle objections from customers?

Posted by Gretchen Freeman-Cromar on October 12, 2011

When managing complex projects we are bound to face some difficult situations. I consider a situation difficult if it meets any of the following criteria:

• There is an acute gap between reality and the current plan. (We are supposed to go-live in an hour and the entire database is corrupt, and the IT director is drunk.)
• Confusion exists about what the gap is, what is causing it, whose job it is to resolve it, or possibly whether it even exists. (What iceberg? I don’t see an iceberg.)
• It’s unclear how resources should be applied to resolve the gap. Fear that taking action or doing nothing may make things worse. (Don’t just stand there, do something! Wait, no. Don’t do anything, you might make it worse!)

Typical causes for difficult project situations are listed here:

• Oversight or realization
• You or your team is forced to do something stupid
• Failing schedule or resource shortage
• Quality is low
• Direction change
• Team or personnel issues
• Disagreement and conflict
• Lack of faith
• Threats of mutiny (acute form of lack of faith)

What makes these kinds of situations difficult is not the situation itself, but the context in which it occurs. During go-lives, many kinds of issues have fuzzy beginnings and endpoints. No red warning light will go off on your desk telling you that morale is low or that an oversight has just been made. You have to look for it, and even when you find it-it won’t always be 100% clear what is going on. Taking action, you may only be able to mitigate it and minimize its impact; it might not be entirely solvable. Part of what to do when you’re in a difficult situation is to dedicate time for maintaining chronic and unresolvable problems at a tolerable level. Here are a few tips on how to professionally do that.

Take Responsibility and Do Damage Control

Taking responsibility doesn’t make it your fault: it means that you will deal with the consequences and be accountable for resolving the situation.  By lending real responsibility to the problem, you instantly make the problem less dangerous to the project. In a damage control situation, you don’t usually have time to explore options or consider alternatives. There is usually something very important that is very broken, and it won’t be clear how it can possibly be resolved. To readily handle and face these situations, here are some tips:

Call an all-hands meeting.

The longer you wait to address it, the more fear the team will have to face. Don’t hide from big problems.

If people are in disagreement, find the point of agreement.

Bring it back to the last point of agreement: ‘Do we all agree that our goals are A, B, and C, and in that order?’ and work forward into the problems you are having.

What is the most recent known good state for the project?

If the damage you’re controlling is technical, find the last good back-up you can restore.

Can the problem be isolated?

Think of a boat that is currently on fire. Can the fire be contained? Can the most critical parts of the ship be protected against the fire? Think of how you can sequester the problem and prevent it from impacting the most critical parts of your project.

Can resources be applied to help with the damages?

Sometimes you can spend your way out of a problem. Throwing money or resources at things can sometimes work if your aim is good and it’s the right kind of target.

Find the point of unification.

Find the important points of unification and agreement and use those to start any discussion you have. You want to start with momentum.

Recognize personality conflicts and then ignore them.

It’s easy to fall into the trap of allowing someone’s personality traits to distract you from the goal of solving your problem. Find  a way to separate those feelings from the task at hand.

Look for mutual interest.

Lay out all the possible ways to resolve a situation, and look for choices that benefit both sides.

No matter what you do, things will go wrong.

If you can stay calm, and break problems down into pieces, you can handle many difficult situations. Taking responsibility will always expedite resolutions, and in extreme situations, go into damage control mode. Do whatever it takes to get the project to a known and stable state.

Read more about project management Theory in Practice Making Things Happen by Scott Berkun.

Posted by Jody Leoni on September 28, 2011

In working with teammates and customers, our ability to communicate effectively is not only key; it is what our customers and team members expect from us. Here are a few things to keep in mind that can help increase your odds for effective, clear communication:

• Outline the issue or opportunity to be addressed
• Agree on a shared reality. Both parties must agree on the current reality as it relates to the given issue or opportunity
• Outline a realistic timeline
• Relay information about the environment in which the team will be working (if relevant)
• Identify what to expect from unfolding events (i.e. risk awareness)
• Create contingency plans (i.e. what to do should something go wrong)
• Agree on preferred communication paths
• If applicable, agree on and execute a relevant feedback loop to ensure the given issue or opportunity is properly addressed

By outlining this information, we enable teammates and customers to be more engaged. We also put them in a better position to react to changing circumstances and unexpected events. This structure also reduces the chances for error and allows subsequent communication to be concise and exception-based. Most importantly, if we follow the above ground rules for communication, we will create an engaged, connected and alert team that can share information in meaningful ways. We’ll also benefit from a team with members who can suggest improvements to each other because everyone is informed.

“The single biggest problem in communication is the illusion that it has taken place.”

—George Bernard Shaw