Want to develop a new product? Where do you start? September 2, 2011
Posted by Judi Otton in : Consulting, Marketing, Software Development, Software Process, add a commentI’ve been working with a lot of companies lately that have never developed a new product from scratch. They all seem to have the same question – “Where do I start?”
The answer is always the same – with requirements, and by requirements I don’t mean a bullet list of features, although that’s a start. By requirements, I mean detailed requirements of what you want the product to do and how it should behave in every situation. Error conditions are one thing that’s typically forgotten. Requirements are also not necessarily functional, for example, the maximum (or target) manufacturing cost is a common, and commonly overlooked, requirement for an embedded system. They say the “devil’s in the details.” In this case, that’s true.
The first question clients have (well, maybe it’s not the first, but it’s the big one everyone wants to know) is “how much will this cost?” Without the kind of detailed requirements I’m talking about, it’s impossible to give any kind of meaningful estimate. That’s why we’ve had such great success creating an initial engagement that delivers requirements and a rough estimate of time and cost. This initial engagement typically lasts between a week and a month, depending on the scope and complexity of the project and gives the client accurate information that they can use to make decisions. We usually find areas of trade-off, like features that could be in a future release, and can balance the client’s time to market and budget needs.
So remember, next time you have a new product you’re developing. Details, details, details!
Training our future workforce August 26, 2011
Posted by Judi Otton in : Business, Education, add a commentThis week there was an article in the NY Times about Gadget Camp, a workshop for girls in River Grove, IL to expose girls to the skills needed to get jobs in manufacturing. I love this idea! As one of the few girls that took (and thoroughly enjoyed) wood shop and metal shop, I wish I had something like this growing up. There’s absolutely no reason girls and women can’t do these jobs.
Through my involvement with the New Haven Manufactures’ Association (NHMA) Workforce Development Committee, I’ve seen personally how many how many manufacturers there are in CT and how many jobs they have. Yes, there are jobs in manufacturing, and not only are there jobs, these are good jobs that don’t require a college degree. They do however require skills, especially math skills, and unfortunately, our public schools are not doing a great job providing them.
Our Vocational schools, however, are providing kids with the skills they need for these jobs as well as a good traditional education. Before getting involved with the NHMA, I didn’t realize that the kids at the Vo-Tech schools took the same academic course load as public schools PLUS training in their field. The kids that I’ve met are bright and passionate about their field. Whether they go on to college or not, they have a bright future ahead of them.
Programs like Gadget Camp and even more so, the Vo-Tech system, provide much need skills and opportunities for the kids that participate in them, and critical talent for our businesses. We should do anything we can to support them.
The Art of Requirements Writing August 5, 2011
Posted by Judi Otton in : Software Development, Software Process, add a commentThe one area where I see companies could improve and make a HUGE impact on their development is in Requirements Writing. Most companies err on the side of too little or, unfortunately, way to often, none.
The biggest problem we see as a result of insufficient requirements is almost always scope creep, meaning that because there is no baseline, features just keep getting added to a release, and the result often is that the release never gets released. The other common problem we see from non-existent or insufficient requirements is that what gets implemented is often not what was intended, and if by chance the implementation is done correctly, it has taken a lot more work, time, and interaction than it would have otherwise.
The other side of the coin is perhaps more interesting. It’s rare, but sometimes we see companies that put too much in their requirements. I think this fear is why some companies don’t do anything at all – they don’t want to spend eons writing reams of paper and analyzing every detail. Rightly so, it’s a waste of time. The kinds of things we see in this area fall into two main categories of content and formatting.
As far as content, the biggest error is trying to turn a Requirements spec into a Design spec, meaning that instead of detailing what needs to be done, the requirement details how it should be done. Now there is a place for this, but it’s not in requirements. Specifying the how in requirements really limits the options and almost always results in a sub-optimal design. If the requirements are being written by a business analyst, as good as they are, they are not usually experienced architects or developers. Even if they are being written by a developer, the benefit to separating what from how allows the developer to look at all the requirements as a whole and in a separate thought step design the how in the best way taking everything into account, not just one requirement.
As far as format, the least useful way to write requirements (and ironically, probably the most difficult way) is in paragraph or prose form. There’s just too much content, and the important points are not easily identified and digested. Additionally, it takes an additional step for every user of the requirements (development, QA, Tech writing) to get the relevant information out. Obviously Use Cases are a tried and true and very effective method, but even bullet points (as long as they contain enough information) are preferable. The information contained should include the user entries, the results, any exception or error conditions and any other affects of the feature, easily and quickly captured in a bullet point format without any extra text to wade through.
Bottom line – well written requirements are HUGELY helpful to everyone in the development process and will make a great impact on getting your product out quickly. I’m sure there are offenses I’ve missed here. What other kinds of things have people seen??
What it Takes to be a Successful Consultant July 21, 2011
Posted by Judi Otton in : Business, Consulting, Customer Service, add a commentI have not written for a while on what it takes to be a successful consultant, but lately I’ve been noticing some common trends with our best people, and oddly enough it has absolutely nothing to do with their technical abilities. I’m really not sure what to call it – grace, poise, or just plain old fashioned professionalism.
In one instance, one of our clients handled an HR problem, let’s just say, in a less than optimal fashion. Our consultants there were affected by this decision, and one of them could have been justified to be hurt or angry, but to his credit, he just continued to do his job while the storm raged around him. He happened to be in our office one day while this was going on and his comment to me was “I have a job to do, and I’m going to focus on that and do my best.” Love that!!
In the second instance one of our consultants was working with an engineer at our client’s client on an integration project. I’ll spare you the gory details but this engineer was engaging in programming practices that would make any professional programmer shudder with disgust. The stories even made me shudder and I haven’t been a programmer in ages! To his credit, our guy worked thru the issues with this engineer without issue.
Although they’re all sharp, in fact some of the smartest people I know, I think I admire the restraint, respect and professionalism our consultants exhibit even more than their technical chops. We serve at the request of our clients, and being difficult or disrespectful does nothing for our relationships. I’m so proud to be a part of this team, with these amazing engineers and developers!
Girl Power! Encouraging News on Girls in Tech July 14, 2011
Posted by Judi Otton in : Education, STEM Careers, add a commentI’ve written a lot on the alarming lack of interest of girls (and boys) in technology careers. This week I read some encouraging news I wanted to share.
Google’s inaugural science fair was held on Monday and the three winners were all girls! Google reviewed more than 7,500 entries to bring the 15 top applicants to Google headquarters for final judging. These 15 were interviewed by luminaries in technology, including a Nobel Laureate, National Geographic Explorers, and some of Google’s best and brightest.
As we know, there is no shortage of younger girls interested in math and science, but for some reason that drops off in middle school, yet these girls were all teenagers. Let’s hope their interest continues. We need smart people like this in technology!
Making the same mistakes June 24, 2011
Posted by Judi Otton in : Leadership, Management, Software Development, Software Process, add a commentI hear it over and over again from technology execs – I know we should spend the time writing specs or working on our process or on architecture or designing a good UI or testing or documenting or – fill in the blank.
Yet, time and time again, I see companies making the same mistakes. It kills me! I asked myself “why do they do it?” After all, it’s so easy to improve your delivery time and quality a little bit at a time. I know it’s hard to find a place to start, but for some companies I see, anything would help them. When in doubt, remember that good requirements make everything else easier!
Then I remembered something I’ve heard repeatedly “The pain of the change must be less than the pain of the status quo”. I get that change is tough, but some of these changes (i.e. good requirements definition) are not that painful. I think a more accurate assessment would be “The fear of the unknown must be less than the pain of the status quo”
Do any of you have less than optimal practices in your product development? We all do, in one way or another. Things can always be better. Why do you stay where you are?
Innovation – Simple Is Best June 20, 2011
Posted by Gary Felberbaum in : Uncategorized, add a commentAs I recover from minor foot surgery I discovered an important fact. The use of crutches is exhausting. The only thing required of me to heal properly was not to put any weight on the foot. Sounds easy but after a few days I found the use of crutches to be limiting and exhausting. Facing six to eight weeks on crutches I began looking for alternatives.
A friend of mine recommended a Knee Walker. At first the scooter, as I prefer to call it, did seem laughable. But when I tried one I could see how such a simple device could be so helpful. After using one for the past 6 weeks I am a huge fan.
So what did I learn from this experience? Some of the most innovative products are the simplest. Entrepreneurs, inventors and engineers thinking of the next great breakthrough product need to ask themselves two simple questions.
What problem am I trying to solve?
What is the simplest way to solve it?
That is a good start for any new endeavor.
Driving Students to Tech Careers June 17, 2011
Posted by Judi Otton in : Education, Software Development, STEM Careers, add a commentI recently read an interesting interview with three senior executives at Google. The article was about women in technology, but one of their points intrigued me. They hypothesized that the prevalence of technology in our lives (smart phones, Facebook, etc.) will drive more young people to technology careers. They will use it and some will be curious about how you create a smart phone or an application like Facebook.
This sounds likely to me. Recently, I was speaking to a group of girls and shared that I had no idea what Engineering was when I went into college. All I knew was that it used math and science and I could get a good job when I was done. That was enough for me at the time. Fortunately, I enjoyed the intellectual challenge of solving problems and the satisfaction of creating something from scratch.
Now a days, when I describe what Advanced Decisions does, I have plenty of commonly known examples to point to. My typical “definition” of embedded systems programming is “writing software for an electronic device like your phone or your car, or your microwave, or medical equipment.” People usually understand that.
Do you think the prevalence of technology in our lives will generate interest in careers in tech? If not that, then what might? One of the points the women made in this article was that it’s not really about just women in tech. We have a shortage of programmers and engineers and need more regardless of gender.
Girls in Technology June 7, 2011
Posted by Judi Otton in : Education, Leadership, STEM Careers, add a commentA few weeks ago I spoke at Housatonic Community College’s Girls in Tech program. See this article in the CT Post for more.
Kudos to HCC for putting this on. It’s such an important issue. These were 7th and 8th grade girls, mostly from Bridgeport that had the opportunity to attend the expo and learn more about what kinds of careers are possible with a good solid STEM education. The possibilities excited them, and fortunately, this is the time to do something about it.
At this stage in their schooling they still have the opportunity to take advanced math and science classes and get the grades required to get into top schools and get scholarship money. This is the age where girls lose interest in math and science, but seeing what they can do with a strong STEM education, many of the girls were inspired.
Choices like nanotechnology and crime scene investigation are not obvious, but really inspired the girls. Many of them said they would devote themselves to their studies, with the goal of entering one of the intellectually stimulating and high paying careers presented at the Expo. I’d call that a success!
To the Cloud March 11, 2011
Posted by Gary Felberbaum in : Uncategorized, add a commentThe next big software war to be fought is in the cloud. I have been following Google Apps since its inception as an offshoot of gmail. Google’s ever improving suite of online software has evolved into Google Docs and for businesses, Google Apps. It is an economical choice for a small business to provide protected email, shared calendar, messaging, software applications and shared access to documents with NO I.T. responsibility.
Now there is a new kid in town, or soon to be. Microsoft is about to debut Office 365. It will compete directly with Google Apps for business and provide a hosted productivity and collaboration environment for businesses. Small businesses who typically cannot afford an I.T. staff or who do not want to maintain their servers will now have a choice.
Google and Microsoft are providing an integrated suite of common office applications PLUS a collaboration platform PLUS messaging. When offered at an affordable price it becomes very appealing. Especially when it does not involve those dreaded server updates and reboots. Let some one else worry about that.
So let’s see how this develops, there are many questions. Does our internet infrastructure provide the kind of responsive we have become accustomed to with our desktop/notebooks and local area networks? How many businesses are going to adopt Cloud computing and store important documentation somewhere out there? How safe, private is this data?
Many questions, the story is now unfolding.
