Assessing Organizational Efficiency

February 23, 2010

Delegation and Authority

OK, now that your organizational structure in place, you should test it to make certain it is actually working. Check to make sure that authority has been properly delegated and understood. For instance, you can randomly ask someone in the organization to explain their current responsibilities. Do they know how they are being measured and what impact that will have on the organization?


How about the interworking of your teams? Do your employees understand their respective roles. Investigate how they work together – what information do they share? Can the communication process be streamlined? You can also encourage teamwork – for instance, you can implement a process to recognize and reward peers.


What about meetings? Everyone complains about them, right? So, you can go to work on ways to improve meeting efficiency. You’d be surprised what implementing simple rules like starting the meeting with ‘the purpose of this meeting is ….’ Check out

There are even ways to improve organizational efficiency by improving their problem solving capabilities. What methods do you use to facilitate idea generation, decision making, and solution implementation. Pick up a copy of The Memory Jogger II.


Organizational Structure

February 16, 2010

As a company grows, the general manager must create the necessary infrastructure for the company to be successful.

Charting Your Course

If you don’t have one already, define the organizational chart required for your company to succeed at the current level as well as the next. It should be defined by roles, not by people. So, for the moment, set a side thoughts about the people currently in your company and describe the organizational structure required for optimal execution of the company. The organizational chart should consist of job titles, not peoples names.

Filling in the blanks

Once completed, you can then add the names, parenthetically under the titles. By the way, it is OK if a name appears in one location. If it is yours, you are simply coming to grips with the fact that you are serving multiple functions, which will then make it easier to define and delegate. But, if it is someone else’s make sure that it is clear that they are serving multiple roles. How much time should they spend on each? What are their respective goals?

Take this job and describe it

Next, create job descriptions for each role in the organization. What are the responsibilities for each job? What are the goals and metrics for each? If they don’t exist, consider having your employees write one for them. It might be interesting to find out what they think that they are responsible for and how they will be judged as successful. Ultimately, get the manager and employee to sign-off on the job description. That’s much better than simply inheriting responsibility and assuming that the employee understands it.

For more information and ideas, check out Chapter 14, Your Organizational Strategy, of The E-Myth, Revisited.

Licensing/Activation for 3rd Party LabVIEW Add-Ons and EXEs

February 9, 2010

In the next version of LabVIEW , we will introduce a new method for licensing/product activation of third-party products (for Windows platforms). You will be able to add a layer of licensing to your add-ons and EXEs to protect your products with a similar sort of mechanism that NI uses. The licensing feature employs a commercial-grade encryption scheme and automated activation system.

How it works

There are two types of licensing that this feature will enable: development licensing and deployment licensing.

  1. Development licensing refers to protecting VIs in the LabVIEW environment. Add-on toolkit developers can use development licensing, so that licensed VIs break when a valid license doesn’t exist, thus preventing toolkit user from using an evaluation/expired version of a toolkit.
  2. Deployment licensing refers to protecting an application at run-time. With deployment licensing, you can develop turn-key, commercial software application built with LabVIEW without the need to implement your own licensing/activation scheme. Deployment licensing will be made feasible through an API, so you check license states and activate licenses through your LabVIEW programs.

Want to learn more?

If you are interested in a webinar presentation to learn more, or to discuss specific software licensing/activation use-cases that your organization faces, please contact:

Jeff Meisel

Product Partner Program Manager / LabVIEW Product Manager

(512) 683-8795

Reasons for Change Management

February 2, 2010

During an presentation about Project Management Practices that I recently gave at the UK Alliance Day, we were discussing the reasons for a good change management process. Some of these, I’ve mentioned in a previous post:

  1. Accurate reflect that there has been a change to the contracturally agreed on specifications/requirements. I think this is the best ‘excuse’ to ‘enforce’ this process with the customer.
  2. Recognition/approval to potential impact on timing and budget. Your developers should be made (painfully) aware that agreeing to changes, cost money. Regardless of whether they can be accomodated (in the timing allowed), you are adding value – and that should be captured and recognized.
  3. Sets precedence for further changes – If you ‘blindly’ accept changes, then it is harder to get it stopped once it gets going. The customer is apt to say, ‘Well, you made these other changes (which may have been bigger). Why not this little one more?”


I also advocate that Customer Change Notifications/Approvals. Even if you don’t intend to charge the customer, the change should be documented, the cost of that change estimated and included on that notification, as well as a separate spot to indicate charge to the customer (even if it is zero).

A couple other reasons

I got feedback from the audience that there are a couple other reasons to follow this process:

  1. Change may just not be worth it – By formalizing the process, you give the customer (and/or your developer) to determine that it just isn’t worth the ‘hassle’ to make the change – including documenting it and getting the necessary approval. In that case, you’ve probably saved yourself some time and effort.
  2. You might just get paid for it. Must admit that I’d probably hadn’t given this one enough consideration. So, you may just want to present Change Notification with the charge included and only zero it out if the customer pushes back. Even then, you established that you are providing extra value to the customer.

What say you?

Getting the feedback from my presentations, reminded me that I should do a better job in these blog posts to ask your thoughts and opinions. Do you have a formalized Change Management process? If so, what do your find effective (or not)?