Month: February 2016

Are we placing importance on the correct skills?

“Software is a list of instructions that tell a computer what to do” (Wikipedia). Instructions, by their nature, can produce the same result, time and time again and can be performed by many users. Once written, tested, and accepted by a user community, collections of instructions become known as “software”. As software matures and updated versions are released, the instructions become common between each of the major programs. Instructions or commands like “open file”, “print”, or “save” are ubiquitous across applications. Even ERP programs have common commands that create a master data record, record a sale, or post a customer payment to an invoice. All the user needs to be shown is where the commands are in the menu structure, what set of business conditions must exist to use each command, and what results successful and unsuccessful transactions produce. Once a user learns how to perform a command rarely does it change. So why do employers place such a high value on potential employees using a set of repeatable instructions with a known result, over and over again?

One would think an employer lists their job requirements from most important to least important in a job ad. Specific software packages are usually called out at or near the top, along with other skills specific to the employers’ work environment. I see many job postings with requirements of “Must have x years’ experience with [fill in your software tool here]” listed first or near the top of their ad. Why is it skills with a specific software package get top billing? Software is nothing more than a canned set of steps in a specific order yet employers place a premium value for prospective employees to have extensive experience with them. Why is that? Packaged software can be easily learned yet employers insist prospective employees have years of experience with their particular software.

Learning business processes, how they work, how they consume and produce data, and where they receive their input is much more valuable than the ability to execute a canned process in a software package. Understanding, and being able to explain in simple terms, what a stored set of instructions actually does and what it produces are much more valuable skills than remembering the code for a certain transaction. Anyone can push a button, type a transaction, or execute a stored command. The value a potential employee brings is what happens after that button is pushed or the command is executed. What is going on in the background while the computer is churning away, busy completing the task you requested? What happens when you post a customer payment to an invoice? What is the business process effect of executing a command that returns goods to a vendor? And where will the transaction end up in the General Ledger? The Financial Statements? Which business processes will be effected by the command you just ran? Far more importance should be placed on the effects of executing a stored command than remembering the code for a command or where it is in a menu structure.

Project Staffing – Can We Get it Right?

For organizations that perform projects (which ones don’t?) there’s a question that invariable is asked at some point: “Do we use our own people for the project or do we bring in consultants and temporary workers?” While there are a few different ways to answer this question ultimately the answer has to be made in the best interests of ALL the people involved. I’ve seen many a project go quickly off course because staffing, communication, and planning weren’t seriously considered. Companies usually fall into one of three categories when making this decision:

  • Use consultants/contractors to perform the project work and let the employees handle the day-to-day tasks
  • Use employees to perform the project work and have consultants/contractors do the day to day work
  • Use the project as an opportunity to have employees lead project teams with consultant Subject Matter Experts (SME’s) to guide them.

In the first instance companies engage a consulting firm with most if not all the necessary project resources. The consulting firm leads the project, performs the requirements gathering, development, testing and, at the end, (maybe) trains the client personnel on how to use their shiny new software tool / process / upgrade, hands over any documentation, and leaves. Any “institutional knowledge” they may have picked up leaves with them. Ideally the documentation they leave behind and the knowledge transfer they perform are adequate for the client to use the new tool they have. Many times the success of the project is solely determined by how well the knowledge was transferred.

In the second scenario employees are thrust into roles they may or may not be familiar with: Project Manager, Business Analyst, Requirements Manager. Most projects initiated by business users depend heavily on their IT staff to move the project forward. Business users often do not have formal project management or project documentation training, leaving those duties to already overly-burdened IT staff. Business users have ideas of what they would like to see or how the new product should function but these ideas get lost in translation between their vision and the reality of well-defined functional specifications. As they attempt to perform their project duties they are constrained by the temporary replacements doing the day to day work.

The third situation requires much more planning and broader, enterprise level buy in for the project. Project training for employees has to happen before the project formally commences. Planning and communication of project management and documentation basics, as well as expectations for phases and milestones, must be clearly laid out before the project begins. Ample time must be allotted for employees to train replacements before they move to the actual project. The enterprise must be willing to invest not only in the project itself but the time and resources necessary to back fill for employees while they embark on the project journey. Once properly equipped, replacement workers and employees are ready to devote their full attention to their new roles.

Which approach is best for your project? It depends on your circumstances, budget, timeline, and level of urgency. I’ve seen the third approach work the best in practice. It requires much more thought, time, money, and resources but, in the long run, it is best for everyone involved. Employees are shown they are valued when the organization takes the time to train them and then allows them to apply their new skills right away. Temporary workers are trained in a new corporate environment, increasing their skills and adding to the professional backgrounds. Learning and professional growth happen all across the organization with much more engagement by everyone involved. Everyone knows their role and has a support network to engage should they need. It may take more effort but in the long run many more people benefit from this type of approach.

So what are your thoughts? What is the best way to staff a project?