11.29.08
Posted in Business, Companies, Management, Software at 5:19 pm by Jan
Working for an Aerospace company in the ‘80s, the dress code was much more formal than it is today. Women wore pant or dress suits and men rarely showed up for work without a tie. While engineers at times dressed less formally, particularly those who stayed in the computer labs or on the engineering floors, they still wore khakis and sport shirts and their managers were always in suits and ties. And everyone showed up for meetings with the customer in business attire.
I was lucky enough during the early ‘80s to have a prime job managing the company’s technology software department which included Research & Development projects in interesting software areas such as Artificial Intelligence, Computer Aided Software Design, and Software Security. A group of very knowledgeable PhDs worked on the Trusted Software Security project. They had been working with the government and with Sun Microsystems for several years, pushing the envelope on secure software and had been awarded steady R&D contracts for several years in a row. The PhDs were well-known in the security circles, often asked to gave briefings at software security conferences.
At a couple of conferences in a row, they’d encountered a young software engineer who they were very impressed with but who lacked the educational credentials to typically be hired into such a the team. But they were all so excited by this young man’s abilities that they convinced me to hire him as their assistant with the thought that they’d over time convince him to return to obtain his PhD.
So Mark, our new Asian security engineer, started working for the team. He arrived at work wearing the T-Shirts and jeans he’d worn on campus at UC Berkeley. On one of the first days he was on-board, I spotted Mark at the other end of the aisle of cubicles as I walked towards my office. But it wasn’t his T-Shirt and jeans that caught my attention, it was his shock of bright orange hair. I veered into his supervisor’s office.
“Did you see Mark today?” I asked.
Chagrined Dave said “Yes, orange. I already talked to him about it but there’s no customers in today so I just told him to wash it out tonight.”
“Humm,” I muttered and went to my office.
I didn’t think much else about it since the next day Mark showed up with his normal, although somewhat long, black hair. And the team’s research was going very well. They were working hard, long hours but were making great progress. Then came the day for the big customer review. An important day to determine how much R&D funding would be awarded for the next year for the project.
The team had decided to have Mark give the demo – he was quicker at the keyboard and the demo flowed very well when he gave it. I said they’d need to be sure he was dressed appropriately and they said they’d already spoken to him about it and one PhD had given him a tie to wear and Mark had described an appropriate shirt already in his closet.
The day of the demo I arrived at work and, walking to my office, spotted Mark out of the corner of my eye and marched directly into Dave’s office. Dave didn’t even dare look at me.
“I know, it’s purple.”
Yes indeed – Mark not only was wearing his normal T-Shirt and jeans, today his hair was shocking purple. Bright purple. But it was too late for anyone else to learn the demo. And the Customers, Army Intelligence Officers, had already arrived and were waiting in the conference room. So nothing to do now but wait for the reports of how it went.
Later in the afternoon the head security PhD came into my office beaming.
“It went great!” He said.
I was wary. “And what about his hair?”
“The customers certainly looked shocked when he entered the room. But once Mark started in on the demo they forgot all about it. He was so knowledgeable and answered all their questions with ease. I’m sure we’ll get our funding next year.”
“But you’d talked to him about his clothes and hair – why did he show up that way?” I said, still concerned that he may just be rebellious which would eventually cause issues.
Mark had told them that he’d gotten up that morning and put the shirt and tie on, looked in the mirror and felt so out of place and nervous he didn’t think he would be able to give the demo or face the customers. He panicked. He was so ill at ease in the uncomfortable clothes. And whenever he dyed his hair, he felt his shocking hair diverted attention which made him feel comfortable and at ease. He was so worried about not doing a good job that decided he had to show up looking the only way he felt confident.
The security project was expanding and we’d hired a woman PhD from the East Coast. She came to start work while her husband and two teenage sons remained back East to wrap up the sale of the house, packing and moving. One afternoon after a week at work she came into my office looking very upset. She told me she had just gotten a call from her oldest son and that her husband had had a heart attack and died. She was worried that she didn’t have any vacation and had just started work. I assured her that she didn’t need to worry about that. To go back East and take all the time she needed – that her job would be waiting for her. I asked her if she needed anything from us and she said she wondered if she could use her office phone to make plane reservations (since at that time calls outside the building were not allowed) but of course, anything she needed.
I stopped by her cubicle during the afternoon and she said that the airlines were very sympathetic and working with her and that she said she’d gotten a flight for that evening. Mark was in her cubicle helping her – he’d asked Dave if he could make sure she had a flight. The next day I learned more. Mark had insisted on driving her home, worrying that she may be too upset to drive safely. He had cooked her dinner, helped her pack and driven her to the airport. I then realized he’d jumped in and done more for her than anyone else at the company had – he had shown real compassion while I had been judging him on the color of his hair and clothes he wore. And I said to Dave, “Tell Mark he can show up with any color hair he wants.”
Prejudice against purple hair seems like such a small thing but most of us have many prejudices. Growing up in Utah, I had been prejudiced against blacks without knowing it. I recognized my prejudices in college and worked hard to overcome them. One day shortly after I started as a software engineer at Ford Aerospace, I was talking to someone about three Philco computer engineers I met and someone asked me “You mean Emery, the black engineer?” I had to stop and think because I wasn’t sure any of them was black. The next day I looked more closely and sure enough, Emery was black. I was so proud of myself that I hadn’t even noticed. Now Mark had taught me to also not judge by the color of one’s hair.
When Barack Obama was born, many states considered his parent’s marriage, marriage between a black and a white, illegal. When we lived in Charlotte, North Carolina in 1978, our company’s black engineer and his blond wife would be yelled at as they walked together down the street or worse - bottles were sometimes thrown at them from passing cars. They eventually had to move to Colorado where the prejudices weren’t so strong.
Jumping to November 4, 2008. Such a wonderful day – where America showed that we have all gotten over so many prejudices during the years. A day of change, a day where racial prejudices have been set aside, at least in one of the most important arenas, the Office of the President of the United States. Yet on the same day California, the most progressive state in the union, voted “Yes” on Prop. 8 to add discrimination to the state constitution. How ironic that we take one huge step towards acceptance and equality and one huge step backwards.
Hopefully it won’t be too many years before we can mature to also accept gays and lesbians and their desire to be married and accepted into the mainstream.
Permalink
08.19.08
Posted in Companies, Management, Project Management, Software, Software Life Cycle at 11:23 am by Jan
We were out boating last weekend (as usual) and there was a group of folks on our friend’s sailboat that began discussing software. Someone causally commented that software, of course, can never really be documented. “Right,” said another. “If you try to document it, then the code changes, and so the documentation is always out of sync. It’s impossible!”
All agreed that design documentation maintenance is an unattainable goal. Some were engineers from a big major networking company, one from a mid-sized software company.
But the advantages of having a real “As Built” spec seem so obvious. A spec that is always updated before code changes are made, that is used by QA for testing and used by Tech Support for customer support and questions, a spec that unquestionably contains the use case scenarios and business algorithms implemented by the code. The advantages of having such a spec is so key to producing clean, quality code and so necessary for clear communications between the developers and the customer advocates (Product Marketing, Tech Support) that it seems to me an obvious requirement for effective software.
Yet these software professionals were in agreement that maintaining such a spec is not feasible. Perhaps I shouldn’t have been surprised. When interviewing candidates recently for a VP of Engineering position, I repeatedly found each candidate had a similar story – whether from a small start-up, a major application vendor, or somewhere in-between – each said they had never found a way to successfully document and track requirements to design to code. It wasn’t feasible, each said. Plus others I knew from a mid-sized software application company had same opinion. Product Marketing creates the Marketing Requirements Document in Microsoft Word. Engineering takes that and creates the design and then codes. At the end of the cycle, although the PM team attempts to maintain the MRD in-sync with the code, they say it isn’t ever really possible. Plus because some MRD documents describe enhancements to existing modules, they are “change” documents, and after a few releases there was no complete document defining the complete feature. One solution companies have tried is to assign the task of writing an “As Built” document to the Technical Documentation team after the code is released. Seems like a good idea? It would only be valid if the document were thoroughly tested by QA but that would require double-testing so is never done. Hence it’s only the tech writer’s best guess at specifying what the code is actually doing.
Yet I still thought these companies were anomalies. Even though, my friend and consulting partner, Anita continually encounters the same feedback from the students in her UC Santa Cruz training courses on requirements management, it seemed that these companies must not represent the majority. Surely most companies must have found the solution. Because the solution was not that hard to find.
But to hear again this weekend the wide-spread belief that maintaining design documentation isn’t viable me stop and take notice. I know the “Agile Software” community discusses the advantages of relatively sparse use of documents. But seems to me that the discussion is at the wrong level. By eschewing documentation we are losing a key component of an effective software process. And what I’m advocating doesn’t need to take more time or effort. In fact, just the opposite. There is a level of documentation that can be easily maintained, aids every organization throughout the software company, and should be as much a part of a normal software development cycle as configuration management tools are. (Hopefully no one reading this blog would tell me they do not belive in checking software into a config management tool). Maintaining real, code-synchronous documentation is feasible and just requires the right tools and corresponding processes.
Yes - it’s an easy problem to solve. At Azerity, my company, we proved that having the right process and not only were feasible, the result was reduced headcount needed to design, develop, and maintain code. It was actually amazing at the size and complexity of software we were able to deliver and support with so few people. And a key component was the concept of complete, “as-built”, tested specs describing each application module. These specs became core to our company, our software bible, the key to our IP, and only the code itself was more revered and protected.
Our journey – how we got there. For the first few years as a start-up, we had effective processes for our size company because we had implemented, from day one, our Tracker tool (see DP Tracker tab) which was much more effective than open source tools like Bugzilla or their equivalents. For a team of less than ten with an application still small enough that key individuals could grasp the entirety of the product in their heads, we were able to implement and enhance the application effectively using only DP Tracker, CVS for code management, and MS Word for specs.
But then we got larger quickly as a company and the application grew. We doubled the engineering team. With plans to double the engineering staff once more we had a major expansion of new modules and enhancements being designed by our new Product Marketing team. We were becoming a real software company.
We hired a VP of Engineering and I took on the CTO position. Her first observation upon arriving was that using MS Word for specs wasn’t going to continue to be viable. And it was quickly apparent that she was right. We had a new Product Marketing team that were making spec changes, the developers were having difficulty tracking what changed from revision one, two, three of the Word docs. Some companies try to handle this by checking the Word documents into a code management system but that still doesn’t help the engineers clearly identify the delta between the spec and existing code.
Anita, our new VP, had recently completed a requirements tracking tool comparison at her prior company and Telelogic’s DOORs product (now owned by IBM) was the clear choice. We decided we didn’t need to re-evaluate tools and we purchased DOORs.
The beauty of the DOORs product is that it is similar to using Word so is easy to learn. But most importantly each requirement is automatically tagged with a unique ID that stays with the requirement even if you cut and paste and totally reorganize the document which isn’t possible with Word or any tool that claims it can export and re-import to/from Word. Each requirement can also be tagged with other attribute columns. For example, we added a Tracker number attribute and other columns. Since DP Tracker was used for change tracking, workflow, developer and QA assignments, and ongoing developer/PM discussions, the Tracker number tied the spec changes to the developer’s work list and the rest of the software process all the way through to QA and deployment. Each time we made a spec revision in DOORs, the latest version was exported to centrally stored HTML files which all developers could access without having to own a DOORs license. Hence although requirements tracking tools are quite pricey, by only having to purchase licenses for the few key individuals that updated the specs, it was still an affordable tool. Tracker also linked to our code management system (CVS) so we had a complete, consistent tracking from specs to completed code to test. I’ve performed a lot of evaluations of similar tools over the years and unfortunately find that most lack some of the key features that made DOORs so effective. Hopefully IBM will continue to support and maintain DOORs. The IBM sales representatives seem to be pushing their Rational tool for software requirements tracking but it is missing key components we found so important.
There were two results of implemented process: (1) Because our tools were linked (DOORs, Tracker, and CVS) the result was a consistent flow from what Marketing was requesting in behalf of the customer, through design, code, test and delivery. In other words, the engineers actually built what the customer wanted and could do so with less time and energy. And (2) DOORs contained true “As Built” specs. QA tested against the DOORs specs as part of their standard testing and so the company was assured that what DOORs contained matched the actual code. Because the DOORs specs were accurate, other teams (Technical Support, Professional Services, Sales) could quickly access (via the HTML exported pages) exactly what the code did or did not do.
The DOORs specs were not design docs in the true sense of the word. No UML or lower-level implementation concepts. DOORs documented the user scenarios (screen shots and descriptive text), business functions, as well as lower-level information (business algorithms, policies enforced, and even database schema). They contained everything needed to communicate organization-wide what the software was supposed to do and did do.
And this approach simplified everything. Engineers were happy because they had clear direction about what to change when. And if a customer reported a “bug”, there was an easy way to tell if it was really a “bug” (developer mistake) or new, previously unidentified need because if it was in DOORs but the code didn’t work that way, it was a bug. Otherwise, not a bug. Code didn’t change without the spec being updated or, if the spec was found to be missing key information, the specs were always updated and tested so always both items, spec and code, were always in sync. The specs were a living, breathing documents. And this streamlined process and total consistency throughout the software life cycle has been proven to improve quality, reduce the delivery time, and enable technical support to provide better customer support with fewer people. Win-win-win.
Contact Jan or Anita if your company does not have a low-cost, high quality software process including a complete set of “as built” specifications for your code. We can help implement the Azerity process and tools at your company to help you sail smoothly through your software development cycles!
Permalink
07.24.08
Posted in Companies, Management, Project Management, Software at 5:32 pm by Jan
Last month, Northern California was ablaze! 1200 wildfires burning – most due to dry lightening, some unfortunately from arson. We went out anyway, spending weekends dawdling on the delta, in an anchorage with our powerboat tied up next to our friends big new sailboat, the sky smoky, the sun reddish through the haze. We should probably have been inside a house with the windows closed for our health! It was apparent to everyone in Northern California that we have both smoke and fire here.
But sometimes the smoke is hard to see even when there’s fire a brewing. Maybe the smoke is just a wisp or the fire is smoldering under wet ashes and everyone just thinks it has been extinguished.
It’s similar with software management. How can you be sure you aren’t missing the signs of your project going astray? Problems brewing under the surface.
The best way is to focus on your customers and how they are perceiving your company and your product. The old adage “The customer is always right.” is a good barometer for gauging how your company and your product are doing. Is there smoke spewing and you are not paying attention or is it smoldering and hidden but underneath the surface?
Almost every company “says” they are focusing on the customer and usually decisions are being made in what is perceived to be the best interest of the customer. But often we think we are working for the customer’s benefit but we’re missing some key points. Are we focusing on only one aspect of what they want yet not delivering what they really need?
For example, how often have you heard a project team say “The customer’s schedule for delivery is on July 7th so we had to freeze the design last week to meet their schedule.” But is the design that was frozen going to meet their needs? Is the code that is being delivered going to best solve their problem? What if the design team was stymied with how to meet the requirements. Should the team just go ahead freeze the design, code and then deliver just to meet the schedule? Where is the trade-off between quality and schedule? Maybe delivering whatever we can in the required timeframe avoids the big explosion, the blow-up that would occur if the project manager had to tell the client that they can’t meet their schedules. But it doesn’t change the fact that there’s smoldering embers underneath the ashes and eventually when the wind blows (when the customer starts doing their final testing) those smoldering embers will erupt in flames. When the software is delivered but it doesn’t meet the requirements, there will be fire. The best managers will be willing to take the heat and tell the customer up-front if the team can’t meet the schedule. Of course, the underlying problem – why the team thought they could meet the schedule but then missed their target – needs to be examined and rectified so the problem doesn’t happen again. But if the team typically estimates well and is able to perform, but for one project there is a snag, then the customer isn’t served by focusing only on one element of the delivery, the schedule. Quality always has to come first. In this case, “quality” means delivering the software which meets the agreed-upon requirements, requirements that truly meet the need from the customer’s perspective.
Project Managers need to continually scan the horizon for smoke that indicates a fire about to erupt. A project manager that declares milestones complete without actually completing the work is always a sure danger sign. Schedule versus quality is just one example but one that seems to occur far too often in real life.
Permalink
06.29.08
Posted in Companies, Customer Focus, Management, Project Management, Software at 6:59 pm by Jan
We lived in North Carolina many years ago (our youngest daughter was born there). On weekends we liked to take rides in the car, my husband and I and our oldest daughter, then two. We’d go into the mountains, visit the furniture stores, or drive off to the sea side. One of our favorite places was Ashville, NC – in the foothills of the Blue Ridge Mountains. It was lovely there in June – just the right temperature. Not too humid. Enough elevation to get away from the early summer heat.
There was a great big old house in Ashville the looked like it could have been a plantation or stately manor. It had a huge porch all the way around the house . The owners had turned it into a restaurant and the porch now had picnic tables set for visitors. We went there the first time with our 2-year old daughter and were seated at one of the picnic table overlooking pine trees. There were no menus but the table was already set with plates and dinnerware. Shortly a woman came to our table and said “Today we’re having chicken and pork. Would you care to stay for dinner?” Not sure what that meant, having expected a menu so everyone could order their choice, we wanted to find out what this Southern option was so agreed and soon large bowls of roasted chicken, pork, boiled potatoes, and black-eyed peas were brought to our table – Southern cooking, family style. I’d never had black-eyed peas before.
Years later I attended a software management lecture by a man from Tennessee who, with his very Southern accent, talked about the “fuzzy P’s”. I initially thought he was referring to those black-eyed peas from the South. But no. He was referring to the 3 P’s that drive a software project: People, Plan, and Product. “People” are the number of heads you can put on the project. And while you can’t gather 9 women and produce a baby in a month, there are some impacts that can be made if the right resources are allocated to the right schedules. “Plan” is the schedule – moving the schedule in or out is an obvious choice and one of the ways a manager an effect the end result. And “Product” refers to how much product (how many changes, bug fixes, enhancements) is included in that release or that service delivery to the customer. Remove some features, save some time.
The three “P”s can be adjusted to affect the end result. But that’s it. Those are the only viable axes in the three-dimensional world of software that can be controlled and still produce a good, product. If axis one doesn’t get shortened, the others will not be impacted. If a software schedule can’t be met, then either more people are needed or less changes / enhancements/ fixes can get into the delivery.
Usually CEOs want it all – they want the product with all the specified features in the timeframe they want it using only the resources that fit their budget. But if the three axes don’t align, something’s got to give. And it’s the software manager’s job to juggle the axes – more people here, less product there. But CEOs push back and too often software managers try to appease them and agree to accept the dictated schedule with the resources allocated and all the specified product features.
And there’s only one result – the hit is on quality. When there aren’t enough resources to do the job right, quality suffers. It isn’t always apparent to the CEO. Perhaps the team even thinks they are doing a good job by delivering the product and making the milestones. There’s a big party to celebrate the release, and everyone is congratulated. But it’s the customers that will be impacted when they encounter the bugs that ultimately will result.
And ultimately this approach will affect the bottom line. It’s another well-known software rule that bugs found by a customer are 1000 times more costly to fix than bugs found during the design phase. If a bug found during design (or at that point, an issue or problem) cost $1 to fix, if it isn’t found in design but rather during coding it will cost $10 to fix. If found during the QA cycle it costs $100 to fix. And the same issue found by the client costs $1000 to fix. Measure it. It’s a fact. Issues found by clients need to go back to the design, impact code, changes are likely to cause other issues, QA needs to be re-done. Manuals updated. Other clients notified. It’s a very expensive proposition. Not only that, it affects the customers’ perception of the company and it’s software.
So why isn’t quality the primary focus since it’s the most expensive error to make? It’s the fourth fuzzy P. “Perception.” As long as the CEO “perceives” that the product is going out regularly, that everything is on track, managers are rewarded and all’s well. Or seems to be. But letting quality slide is a slippery slope. If no one is tracking the overall quality metrics, quality can slide without anyone noticing until the product has degraded to the point the customers rebel. Take the Microsoft operating system years ago where the blue screen of death was the well-know scenario.
Bottom line – the trade-off should never be quality. Good software managers need to watch their P’s and their Q.
Permalink
05.16.08
Posted in Companies, Software at 3:11 pm by Jan
We had the opportunity last month, as my husband’s retirement gift, to attend the launch of his company’s latest satellite at Cape Canaveral in Florida (Kennedy Space Center). Since I spent the first 20 years at the same company working on satellites, it was a thrill for both of us. We’d never seen a launch before.
This was a special satellite – the largest ever launched at the Cape. With solar array panels that would unfurl to the size of a basketball court. A flexible antenna that would would spread 40 feet, large enough to provide satellite communications for the entire US.
 |
 |
But even more special was the fact that this satellite was, unlike any of the other satellites my husband’s company builds – communications satellites for various countries or for Intelsat, weather satellites for the weather service – this satellite was commissioned by a small start-up company. Only 50 people. All part owners of the company. And so they all came to watch the launch with their spouses and small children. Their entire company rested on a successful launch. And the riskiest part of a satellite launch is from the launch pad to orbit. Risk of the rocket exploding on the launch pad, an explosion as it is being hurled into space, or a failure during the separation stage. Satellites take 3 years to build. Even though insured, a replacement satellite would take at least 2 years to build. A big risk for a start-up ahead of the competition with new technology and leading-edge ideas.
And so it was, with breaths held in, that everyone watched from the balcony of the observation platform as the rocket’s engines began to spew billowing smoke and with a roar, the huge weight rose from the launch platform. The cheer was heard from the crowd and everyone hurried to the monitors to view the rocket perform through it’s roll and booster separation stages. Mission control provided ongoing updates of the status of the satellite – 5,000 miles above the earth, 10,000 miles until, 30 minutes later, it reached it’s destination 19,400 miles high over Australia where the satellite module performed it’s final separation from the rocket, free to use it’s own thrusters to raise to it’s final elevation and begin to unfurl it’s solar arrays. It would be several weeks until it was completely positioned with the antenna unfurled and ready to begin to transmit but the high-risk part was over and everyone could breath a sigh of relief. A successful launch! It was a thrilling event to attend.
One of the company’s Board of Directors said “I’ve been on the Board of many start-ups. But never in my life have I had the experience where so much rested on 30 minutes.”
But was he right? True, it was very apparent the risk and rewards of that 30 minute timeframe. But are other time periods, other moments of lesser importance? In Dan Millman’s “The Peaceful Warrior” books, Dan’s teacher Socrates, drives home the lesson that there are no ordinary moments. Socrates teaches to be aware of your every movement and to appreciate every task. That the more we are able to live in the moment, the more we get from our lives.
How does this apply to companies and managers? It’s surprising how often companies have no real direction or worse, no sense of urgency. Most companies think they have both yet an outsider can easily see that they are not moving forward but rather in a circle. March’s blog talks about the use of metrics to measure the real progress. But you can also recognize moving in a circle in other ways. How often have you been to meetings and realize that the same meeting was held six months or a year ago with the same resulting list of goals or same decision yet people walked out of the meeting and months later there was no action. Often we move along in a daze, without making progress towards the goal but not recognizing it, much activity but very little progress. Measuring progress with metrics is a way to tell how you’ve done. But to really be effective, one must be very focused on the small details, all of the pieces – each moment where a decision or lack of action can make the difference between success and failure. So when we think that it’s OK to just do the minimum required to meet a schedule, that as long as we deliver something on time, even though we know it has a minor quality problem here or a known issue there, we are saying those are the ordinary actions most companies do and they squeak by so why shouldn’t we? Why should we keep trying for perfection when we can get buy with less?
A 30-minute launch is extremely spectacular but let’s not forget that moments that seem ordinary can end up having a huge impact downstream. If we could recognize how special each moment is and act accordingly, wow. Wouldn’t that be spectacular.
Permalink
04.08.08
Posted in Companies, Metrics, Project Management, Software at 8:26 pm by Jan
As the Olympic Torch heads towards San Francisco and what should be an event that joins nations together instead has been mired in controversy, I think of how often one person carrying a torch can bring to light issues and needs that otherwise would remain in the dark.
In a company, torch bearers are needed in every organization. It’s easy to get in a rut of complatency, doing your job day after day. Often no one notices the slow deteriorization of quality or effectiveness.
Another way of saying it may simply be that no one is “watching the ship.” Some might argue “Isn’t that just a normal part of good management?” But to that I’d respond “Yes. But…”
Yes. It’s true that good managers continually monitor and measure performance. But after 30 years in the software business I can also say it’s common for even good managers to get focused on the wrong metrics. Or focused on fighting fires and the performance and process metrics go by the way-side. Or focused on following the company mantra and miss the signs that indicate real, underlying trouble.
March’s blog talked about the use of metrics to identify and quantify changes in effectiveness over time. But often the message that the metrics are elucidating go unnoticed unless people are ready and willing to carry the torch to help the decision makers and top-level management see the light.
Permalink
03.30.08
Posted in Companies, Management, Project Management, Software at 2:45 pm by Jan
It’s March already. As days, months, and years pass by, often we just move ahead, one step after another, and don’t lift our heads up to see if we’re going in the right direction or what progress we’ve made. Periodically we need to stop, step back, and assess our progress and how we’re doing. True in life, true in software companies.
Sometimes in a software company, all organizations are hard at work but something is amiss. In one software company, the technical support team was feeling that the customer’s needs weren’t getting addressed yet all of the product organizations were working hard, producing new releases with client-requested enhancements, and regularly issuing standard bug fix maintenance releases. All of the orgs felt they were busy and overworked but that the product and quality were on track. But by using metrics, they were able to assess the real status.
Metrics were evaluated about the number of customer calls currently being reported that were product bugs or other product issues versus the number one year prior and two years prior. The metrics included turn-around time to get the issue resolved.
What was clear from the metrics was that the number of bug reports had been steadily increasing as new clients buying and installing the software and existing clients were steadily upgrading to the newer releases. In parallel, several new projects were underway, stretching the bandwidth of the product marketing, development and QA orgs. So instead of trying to quickly fix all newly reported issues as they came in, which had been the process in prior years, in order to reduce workload on the developers and QA, fixes were being pushed out to maintenance releases two, three, or more months in the future instead of the next planned release. As a result, more clients were finding related product issues and more issues were being escalated. So to appease the clients who complained the loudest and wouldn’t wait for the future releases, the clients were sent one-off class files, tested only by the support organization instead of QA. If multiple clients needed the change in different releases, the developers zipped up sets of fixes. Then confusion ensued about which client had what file and instead of easing the load, this new degraded process was actually increasing the amount of work due to more call and more one-off fixes. And as a results, the overall product quality was impacted, causing more client frustration. When compared with prior years where bugs were immediately categorized and important issues quickly fixed, now there were too many fire drills and much confusion.
Metrics in this case uncovered both the negative quality trend and the underlying cause. But there is a right way and a wrong way to use metrics. A company can recognize metrics used in the wrong way when employee behavior is effected in non-useful ways. For example, one company used metrics to measure their Technical Support response time and rewarded the techs for maintaining 90 percent first-customer-contact turn-around time in less than four hours. The TS metrics looked great but in reality what the techs were doing was that when they received an automated call from a client, they would place their return call during the lunch hour or just after the company closed, raising the probability that they would be able to simply leave a voice message thereby responding to the call within 4 hours but without having to spend time discussing the call or resolving the problem which could tie them up and make them miss another client’s 4-hour call window. As a result, clients were not talking to a human for one, two days or up to a week and were playing “telephone tag” and getting frustrated.
In another company, a percentage of each developers merit plan was based on low bug count. But often issues reported by users as “bugs” were in reality items that were never spec’d or were spec’d incorrectly. So a lot of conflict resulted, arguments between the development org and support arose (“It is a bug.” “No, it isn’t a bug.”) Team members became opponents which created organizational silos and mistrust. Once the underlying issue was realized, the process was changed and a new Tracker category was created separate from “bug” or “enhancement” to denote a design flaw or spec bug. This allowed the Technical Support team to push that the issue was perceived to be a bug in the client’s eyes and thus get the problem resolved in a maintenance release rather than wait for the yearly enhancement releases. But correctly removed the “blame” from the development organization since the issue wasn’t caused by a coding or process issue like a real bug would be and the correct metric was then being used to measure developer performance. The finger-pointing and arguments ceased, silo walls came down, and the product organizations coalesced into a supportive, cohesive team.
It’s easy to maintain status quo – to march along without noticing the slow and gradual deterioration of quality and effective processes. But by stepping back periodically and reviewing key metrics, teams can make sure they are working effectively and efficiently.
PS: Make sure you have measurable metrics - use Tracker to track Calls, Bugs, Enhancement requests and more. For at-your-fingertips metrics for future use.
Permalink
01.31.08
Posted in Companies, Entrepreneur at 8:45 am by Jan
Sounds like a song title. But neither rainy days nor Mondays get me down now-a-days. In fact, just the opposite. Now that I don’t need to get up before the crack of dawn, get in my car, and drive two hours to get from Discovery Bay to work in Silicon Valley but rather can work from home looking out at the water and my ducks, with a nice fire going in the fireplace, I really like rainy days and Mondays. Cold, rainy days give me justification for having the toasty fireplace going all day. And Mondays I’m refreshed after having taken a little break from work (although my husband does think I’m basically glued to my computer even on weekends). And now-a-days I’m focused on a different kind of rain.
In January it rained. Referring to both the weather and the work. Good for the pocketbook but not good for my fledgling Duck Pond Software and my newly proclaimed entrepreneurial vision of the new company of the 2000s. In other words, I spent almost full time contracting back to my prior company Model N. I did most of it working from home, so it wasn’t like I gave in totally to the corporate structure. And it was fun. But still . . .
The first half of January was more typical for me - part-time Model N work (split between getting my briefings ready to present at Rainmaker, the Model N user conference to be held in February in Phoenix, and on designing a new Rebates module) and part-time moving Duck Pond Software ahead with potential partnerships and customers. Then mid January I got a call from three Model N managers all excited and panicky because of a potential hot new customer deal and marketing arrangement if they could get their software integrated with SalesForce.com tout de suite. This meant an immediate full-time diversion in order to get a live demo up and running in a couple of weeks. The CEO wanted to make an announcement at Rainmaker about a Model N/SalesForce partnership. It was, to our CEO, one of the biggest announcements Model N had ever made. Besides diverting me, they said they’d assign Freeman full-time. That’s what made it fun.
Freeman and I have worked together for about 15 years through four companies. I hired him initially right out of college. He proved himself quickly, becoming the software architect at Azerity. He’s a brilliant and creative engineer but at the same time practical, down-to-earth and loads of fun. He was probably the first engineer who worked for me who was the age of my daughter. But rather than making me feel old, his wit and liveliness always kept our work fresh and fun. Plus he lives and works in San Diego (Model N’s one remote software engineer besides the offshore team in India) so my working from home wouldn’t be a problem on this project at all since he would be working from his home too.
Long story short, we spent two hectic weeks but delivered the demo, got kudos from everyone, and the CEO had the joint announcement for Rainmaker. And the January paycheck was also very sweet. But in the end, it’s just a paycheck received while building on another entrepreneur’s dream versus building momentum towards my own dream.
It was the last hurrah for Freeman and I working together which made it a bitter-sweet success. Freeman joined a start-up locally in San Diego at the end of our project. He’s going for the entrepreneur dream getting in as the third member of a team not even officially a company yet. However, I wouldn’t be surprised if we work together again some day.. That’s the cool thing about the new companies of the 2000s.
It’s like the website LinkedIn and other networking sites that are springing up. People in this century want to be building their own dreams, not working for big corporations where there’s a single entrepreneur who’s the only one who ever makes it big. We all want it our own way.
We want to make our own rain.
Permalink
12.18.07
Posted in Companies, Entrepreneur, Software at 3:03 pm by Jan
While I was pondering the last few weeks about what to do with my new “retirement” spare time and my newly-negotiated rights to SD Tracker, I was spending time surfing the net (I can’t golf 24 hours a day). Several different things came together in my mind’s eye as a flash of intuition. My son-in-law Shane is ahead of me on this, but for me it was an epiphany. As I said in my prior blog, I was weighing options - full-time retirement (lots of golf), another exec position in a start-up, my own company, writing those books I’ve wanted to write, or something else. But what? What form would my days now take. And that’s when I realized that there’s a new kind of corporate structure starting to appear for 2008 and beyond - and it shows a lot of promise. There were three prongs that came together to form my ephipany.
First, my daughter Julie had been pursuing (in addition to working on her PhD) an alternate type of job in multi-level marketing (MLM). MLM - own your own business, build recurring revenue, have independence and financial security. She saw mlm as the alternative to years of 8 AM to 7 PM jobs with no vacation, pressure and only whatever savings you could religiously put aside to use at the end for retirement. Instead, her thought process was that the NextGens should push to break out of the envelop and look at work and life differently. I mean I loved being a co-founder in a start-up and building a traditional business. But when it came down to the bottom line, it’s the VCs that almost always win the big bucks and the rest of us are back to the grind stone. Recurring personal revenue - could that be the key? But after years of dedicated determination working to build the team needed for the sustained income that the MLM dream paints as the reward, she found pitfalls in that you still need to rely on the parent company’s management to not make dumb decisions, not jack the prices up, not make marketing decisions that totally wreck your game plan. So that didn’t seem like the nirvana it claimed to be. So then what?
With my semi-retirement and newly found time on my hands, I was browsing my son-in-law’s website since he’s been after me to add a blog, but, well, although I’ve been building web-based software for years, I must admit I haven’t jumped on all the social networking sites (FaceBook, YouTube, and the likes) and haven’t taken to blogging. Shane joined with a partner Peter to start a new company Shane & Peter and their business is skyrocketing. I have to admit I didn’t see it as a real business for the first few years - I mean the guy was giving away websites in exchange for everything from the wedding cake to the wedding dress (not that I’m complaining - it sure did help out on wedding costs). But then I started reading his blogs and I think he and his friends may be onto something here. It’s a new type of business model and it seems the internet is a-buzz. New internet companies are springing up and everyone is trying to figure out how to convert them from hobbies into substantial money-making ventures. A bunch of them are referencing Shane’s articles on Shane & Peter. Shane seems to have hit upon the goldmine approach and is leading the charge from the old type of corporate structure to new companies forming instead that are network of consultants, contacts, other companies like them. Shane & Peter can quickly and effectively put together a team to meet the needs of major corporations. Shane & Peter’s client list is impressive and proves their new corporate structure works. So that was the second prong, the second “Ahah”.
But it’s not just occurring with the NextGeners. The third prong in the wheel was when we (my husband Mike & I) traveled last summer to Canada and on the way stopped off at friends house we haven’t seen in years. Bob was one of the first folks I knew to leave the big company (Microsoft) and venture out on his own starting The Socrates Group. That was bought by another company. Today he has re-started The Socrates Group but in an entirely different structure - a group of loosely-networked consultants. Not everyone needs to belong to the real “company”; most are independendent contractors. Starting to sound familiar? It’s allowing him to be independent, creative, but maintain control of his own destiny. Same solution for a Baby Boomer hippy as well as a NextGener.
So I’m thinking that it’s 2008 and time for an entirely new type of company. The individual entrepreneur, the loosely linked team of professionals working their own way on their own time. See Shane’s blog linked to my home page. Shane and Peter started their company in a coffee shop but as their friend Quinn blogged “Coffee Shops are so 2005″. Quinn’s “office” is his fully equipped, satelitte antenna/wireless VW camper. So what is the Corporation for 2008 and beyond?
I’m not sure what it “is” but I know I want to move into 2008 - it’s time to combine the joy of living on a duck pond (my new company motif) while linking with a wide assorted network of professionals leveraging their talents and together providing more benefit to existing major corporations than any of us could individually or as part of a single large corporation
That’s what I’d like Duck Pond Software to be all about - exploring a new kind of company and helping other companies while I’m at it. Because regardless how the software is being built and the projects and services are being implemented, the basic processes remain the same.
Because just as the old aerospace tools and techniques were refined and simplified over the years and for my start-up, Azerity, made us lean, effective, and efficient, those same web-based tools and simple basic methodologies can help the NextGen companies (and even ex-hippy companies) in 2008 and beyond.
Permalink
11.30.07
Posted in Companies, Entrepreneur, Software at 9:08 am by Jan
After more than 30 years in the software business, I’m not driving to work every day. Surprisingly, I left my prior company without having a new company to go to. My husband says I’ve “retired”. I don’t know what that means. The beauty of being in software is that as long as you have access to a computer, you can do all of the fun activities you did at your job (but just not get paid for it - humm.)
I’ve worked in the big aerospace and defense software world, been a software exec in various commercial software companies, done the “start-up” bit. I’ve proven that the “80’s” development practices and procedures can be leveraged and changed to work for the 90’s and 2000’s. I might say (humbly I hope) that I always was a great software manager - my reputation was on-time delivery, teams that were motivated, all that good stuff. At my own start-up, Azerity, we produced a product that competed with the big gorillas (SAP, Oracle) and won every time. I’m not stretching now - that software was used by major corporations for mission critical tasks (quoting, pricing) and was reliable (never crashed - really), scalable (30,000 users worldwide), and high performance (just what you want from a web-based system - click click click - screen after screen snap, snap, snap). And it didn’t cost the clients millions to install and millions more to upgrade (semiconductor companies may be big but they are very, very cheap!) When we were bought by a bigger company, within 9 months, the acquirers made more in software sales of our product than they paid to buy the company.
So I went back to the company that acquired Azerity and negotiated the rights to relicense the tool we’d built, SD Tracker.
So now the question is this: Go back as a VP Engineering at an existing company and use SD Tracker and processes and lessons learned and do it all again? Take SD Tracker and start a new start-up going after VC funding and that whole gig? Golf every day? Or some combination of all of the above.
By the way - the other change last year was moving out of Silicon Valley to Discovery Bay - “Live where you play in Discovery Bay” is our city’s official tagline. (Or an alternate is “A small drinking town with a boating problem.”) Both fit. Wonderful place to live - BUT, a 2 hour drive to Silicon Valley where the companies and action are.
We built our house on Drakes Drive, have the Delta (Sacramento River) as our back yard. Wake to the sounds of ducks, geese, and seagulls outside our bedroom window, golf on a lush course abounding with lakes (i.e., duck ponds). Seeing a theme here? So I named my fledgling company “Duck Pond Software”. At a minimum it’s my DBA for consulting back to my prior company for a while. But … maybe more…
Permalink