The new employee selection and hiring process is important for any business, but it is uniquely important, and uniquely difficult, for software development organizations. Many organizations conduct a hiring process that overemphasizes the assessment of some of the candidate’s qualities, while ignoring others that may be more important. A balanced approach, and more reasonable expectations, can lead to a more efficient hiring process. Continue reading
by Justin Hall, CIO
This story begins in the very early days of the space program, when NASA and its vendors IBM, Grumman and others were looking to hire staff to work at Cape Canaveral. The advertisement was simple: they were “looking for many good people.” Interviews and hiring were conducted at a very fast pace, and the competition to get good people was at a then all-time high. I went to work at IBM, which had the mission to build and manage the Instrument Unit (IU), the “brains” for each of the Saturn Vehicles (which we all referred to as “birds”).
Those of us (about 25) who were starting with IBM were being temporarily housed in a very large NASA building several miles from the Saturn rocket Launch Pad. In the corner of several of the conference rooms in this building were racks of schematic diagrams for each of the major systems that IBM would be responsible for: Guidance Computer, Stable Table, RCA 110 computers, Ground Network, Power Systems, AGCS Network etc.) Each person was assigned to the area in which they would be working.
The management team instructed us to remain in the conference rooms except at lunchtime. Those were the only instructions we were given. No one mentioned or even looked at the schematic diagrams lying in plain sight. We could do whatever we wanted, (read magazines, newspapers, play cards, etc.) We were going to be in the room between four to six weeks; by the end of the first day, the schematics remained unnoticed. By the second day, one other employee and I picked them up and learned that they covered all the systems for which IBM would be responsible. We at once began tracing circuits and drawing simplified diagrams. By the end of the fourth week, we knew how all the systems were interconnected and how they worked. The two of us continued working while the other new hires waited for instructions.
At the end of the waiting period, our new team moved to the launch facility to assist in verification procedures for the operation of the ground support equipment. We did not yet have a bird on the pad. About the time we finished verification on the ground support equipment, the various pieces of the Launch Vehicle “bird” arrived. The first and second stages of the vehicle were stacked, mated and connected, and then the Instrument Unit mounted on top of the second stage. Now it was time to ‘power up’. Both my friend and I were assigned to networks, and we weren’t happy because we drew Block House assignments instead of getting in the AGCS area (computer room under the Launch Vehicle) where all the cool equipment was housed.
Two days later, IBM had all stations manned for the initial power up of the IU. Picture twelve IBM systems engineers sitting at their consoles, a NASA Test Supervisor and an IBM Manager ready to get started. The NASA Test Supervisor said to the IBM Manager, “Power up the IU,” and guess what happened? The IBM Manager did not have a power up procedure. Imagine the pregnant pause and embarrassment! I then noticed a brown inter-communications envelope lying on the console next to me. On the back I wrote the twelve steps my new colleague and I had formulated in procedure format and quietly handed it to the IBM Manager. He read off the steps and the IU and all systems successfully powered up. The test was officially recorded as being successful.
If you want to “gain your fame,” look around and see what needs doing and offer to do it. If your skills don’t match what the task requires, consider getting those skills. There are people out there who wait to be told what to do, and there are people out there who do what they think is necessary to get the job done. Here at Bridge360 we strive to fill our teams with the latter, because that’s what we think is best for our clients. We look for people who take the initiative, like to solve puzzles, come up with ideas and become immersed in our clients’ business… always looking for better ways to do things.
Change is hard. Project teams frequently resist the addition of new processes and procedures, and one process frequently fought is the creation and review of requirements. The reaction is understandable—it’s most likely resistance to creating more work in the midst of already tight schedules. On the other hand, some of the consequences of not having requirements or having poorly thought out requirements are:
- Developers guessing how the application should behave
- Secondhand guessing: testers guessing how the developers guessed the application should behave
- Customers not liking or having difficulty with the product
- Spending time and money reworking a product to remove ambiguities
- Inability to map test case to requirements, which can lead to not really knowing if the testing is complete
The benefits of creating requirements and making them clear in the first place are numerous. Here are just a few:
- Understanding the purpose of a new feature
- Understanding the workflow of a new feature
- Understanding the options of a new feature
- Understanding how a new feature integrates with existing functionality
And that’s just the beginning of what ultimately amounts to a little time spent upfront for maximum gain and minimizing stress on a project.
Creating requirements does not have to be an exercise in torture. Even the most basic requirements list is better than no requirements at all. Whenever there is functionality without requirements, developers and testers will make assumptions on how each thinks the functionality should work. Those assumptions may not match the intended behavior. By at least starting a list with the most basic of the requirements, early misunderstandings of what is expected can be avoided.
Additionally, the more people that review the requirements as early as possible, the sooner questions about functional behavior and whether certain functionality is even possible can be raised and potentially save large amounts of time and money. Reworking requirements adds delays and costs to any project, so the better the requirements are to begin with, the more efficiently the project schedule and budget can be maintained. Reworking code over and over and the subsequent testing of that code can add even more costs and delays until the project team can agree on the desired functionality. The earlier everyone has the same understanding of what needs to be done and the desired outcomes, the more quickly a project can progress and the more quickly new personnel can get up to speed on what they need to do to help complete the project.
When requirements are organized well and are succinct and clear, it is easier for developers and testers both to meet those requirements and map specifications and test cases to those requirements and improve the product quality from the beginning. By having better quality early on, the odds of getting a project completed on time and on budget are greatly improved.
by Phillip Smith
Those of us in the service industry do not always have something tangible to show as a result of our work. Compare us to people who build things (like roads, or boats, or furniture) or to people who refine, grow, weave, or clean (to provide fuels, clothing, or foods) and we’re quickly at a loss to point to anything physical that is the result of our efforts. Extend the comparison a bit further to folks who perform, write, invent, or design, and we still fall short in terms of having a tangible product. However, that does not mean that we, specifically those of us who sell or provide a service, are not building something.
Consider the absolute best outcome of a good day’s work in the service industry: the result is a new or improved “relationship.” Yes, people who work in sales and service are building; they are building relationships.
To the casual observer, it may appear that they are explaining the features of a product, or in the case of something closer to my daily work, deploying high quality software into your business environment. And that is the day-to-day picture of what we do. However, the observer who is looking a bit deeper sees us doing more than filling a role in order to put food on the table. We are building expectations, trust, and ethical standards that result in long lasting high value relationships. In these cases “tangible” falls short of being a good measurement of value because the end result is anything but an end. Solid relationships, new processes, better standards—these have a ripple effect in the way people do business, and even if the work didn’t result in the next greatest invention, it’s still the kind of stuff that changes the world.
I’ve not presented anything revolutionary in this article. I’m hoping however, that I caught your eye with the title and that you’ll be willing to think about your hiring, training, and culture in a slightly different way. You would not assemble furniture using an unreliable design or with poor quality components. You should think of the people in your service company the same way that you think of the materials that you might use to make a salable product, with the exception that you are using these people to build relationships that make your business successful.
Are they the best people you can find? Have you trained them well and set them up for success? Are they true critical thinkers, not satisfied until they’ve found the best way of doing something? Have you set the right example with the relationships that you maintain with your clients and with your employees?
Have you communicated the right message to your employees, so they understand how to win repeat business? A smile and a willingness to view the service from the client’s point of view is a key ingredient to repeat business, and it’s not always something you can teach. The people that do your smiling are doing what they love, caring about the results and invested in the outcome—and they are the equivalent of the grapes that go into a fine wine.
The third and final compliance standard that I’ll comment on in our series on compliance is the Health Insurance Portability and Accountability Act of 1996 (“HIPAA”, usually pronounced “hip-pa” even tho there is only one “P” and two “A”).
HIPAA is a very large and complex law that covers many facets of medical care. I am most interested in the portions that involve the security and privacy of health data, those portions protect you so that your medical information is not available for anyone who is interested.
In addition to all the usual information technology security aspects, HIPAA has some interesting compliance requirements. HIPAA requires documentation and disclosure to you of who updates your medical information, as well as tracking and documentation of who reads your medical information when. It also safeguards verbal discussion of your medical information.
For example, if two doctors meet in a hallway and begin discussing your medical information, there are potentially two HIPAA violations happening. First is if the second doctor is actually involved in your treatment, or if the first doctor is just spontaneously chatting about you. It’s OK if that first doctor talks generically about your medical condition, but that doctor is not supposed to mention specifics about you such that someone could figure out it was you the first doctor was talking about. Secondly, the two doctors must ensure that no one overhears them discussing your medical information. A hallway is not a good place to discuss confidential information such as you and your medical information.
One initial problem with HIPAA was that it lacked enforcement and lacked significant penalties. That was solved by the American Recovery and Reinvestment Act of 2009 (“ARRA”). Besides providing a stimulus package for the economy, it also significantly expanded HIPAA’s privacy and security regulations, including increased enforcement and penalties for HIPAA violations. Civil and criminal penalties for violations were increased, and most significantly, state attorneys general were given the power to prosecute and seek civil penalties for violations. You can now search the web for “HIPAA violation cases” to see reports of companies being fined, people being fined, people being fired and people being sentenced to jail time for HIPAA violations.
So HIPAA and ARRA’s enhancement to it are important, because they protect your medical information from just anyone learning about your medical condition(s).
If there are other compliance standards that you are interested in having me write about, please let me know at firstname.lastname@example.org. I am more knowledgeable about the information technology and business continuity aspects, but I can comment on most of them.
This is the last of a three-part series on compliance presented by John Kulas, a software security analyst for Bridge360. John is a Certified Information Systems Auditor with over a dozen years experience across at least a dozen companies. His technical background includes 23 years at IBM. Today, he assists Bridge360 client Xerox/ACS in meeting compliance standards, and enjoys helping non-technical business people understand compliance requirements.
In my previous blog, we began a discussion on technology-related compliance standards, why we have them, how they work and the specific ways in which they protect us. I introduced the Payment Card Industry Data Security Standard (PCI-DSS) as one of the most well-known and widely applied standards in the U.S. economy.
Another major standard that many larger companies must comply with is the Sarbanes–Oxley Act of 2002, more commonly known as “SOX” (pronounced “socks”). Let’s talk more about SOX, because it has made some pretty big news over the last decade.
Why compliance you might ask?
Why do we need compliance,what good does compliance do?
I’ll define “compliance” in terms of obeying a request, a law, or, in particular, a standard. Obviously there are usually penalties if you are not compliant.
- If you do not comply with someone’s request, that person might be angry with you;
- If you do not comply with the speed limit sign, a policeman might observe your non-compliance and either write you a ticket to pay a fine or maybe remove you from your car and haul you off to jail;
- If you do not comply with a standard, depending on which standard, there are a variety of penalties, ranging from fines, mandated actions, delisting your company from the stock exchange and/or imprisoning your corporate officers.
I am a Certified Information Systems Auditor (a “CISA”, certified by ISACA, see http://www.isaca.org/Certification/CISA-Certified-Information-Systems-Auditor/What-is-CISA/Pages/default.aspx) so I am most interested in the 3rd example. In the next few posts I’ll comment on three fairly well known technology-related compliance standards, why we need them, and how they work:
- Payment Card Industry Data Security Standard (“PCI-DSS”).
- Sarbanes–Oxley Act of 2002 (“SOX”)
- Health Insurance Portability and Accountability Act of 1996 (“HIPAA”), and the American Recovery and Reinvestment Act of 2009 (“ARRA”)