Uncategorized | Hub Tech Insider

Boston Project Manager, Paul Seibert April 24, 2013

Posted by hubtechinsider in Uncategorized.
Tags: boston, Hub Tech Insider, HubTechInsider, Paul Seibert, Project manager
add a comment

Boston Project Manager, Paul Seibert

Want to know more?

You’re reading Boston’s Hub Tech Insider, a blog stuffed with years of articles about Boston technology startups and venture capital-backed companies, software development, Agile project management, managing software teams, designing web-based business applications, running successful software development projects, ecommerce and telecommunications.

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. I have been working in the software engineering and ecommerce industries for over fifteen years. My interests include computers, electronics, robotics and programmable microcontrollers, and I am an avid outdoorsman and guitar player. You can connect with me on LinkedIn, follow me on Twitter, follow me on Quora, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m a PMO Director, a serial entrepreneur and the co-founder of several ecommerce and web-based software startups, the latest of which is Tshirtnow.net.

What are some good books on User Interface design? How do you define user interfaces in your software specification documents? The Hub Tech Insider User Interface Design Bookshelf July 31, 2011

Posted by hubtechinsider in Agile Software Development, Ecommerce, Mobile Software Applications, Product Management, Project Management, Social Media, Software, Uncategorized.
Tags: Information Architects, Luke Wroblewski, Microsoft Visio, Om Malik, product management, Project Management, Project manager, Rich Internet Application, User Experience, User interface, User interface design
add a comment

Image via Wikipedia

The Hub Tech Insider User Interface Design Bookshelf: Essential UI Design Books for IT Directors, Project Managers, Program Managers, Software Requirements Engineers, Business Analysts, User Interface Designers, Graphic Designers, Interaction Designers and Information Architects.

Some of the tools that I typically use to produce wireframes and mockups to specify software that is under development include traditional desktop personal computer graphics application software packages such as Adobe Illustrator and Photoshop, business graphics and diagramming packages such as Microsoft Visio, and many others, including some on the Mac OS X and Linux platforms.

But no matter which software program you use to prepare your wireframes and mockups, you still need to have the knowledge surrounding what types of controls are available, and the wisdom to know the most apropos situations in which to use those software controls.

It may be surprising to many people that are not involved in the software industry, but it is not always system and application software programmers who are the most familiar with these types of user interface interactivity patterns and controls. User interface designers, graphic designers, and information and interaction architects are usually the ones who specify these types of “Web 2.0” controls.

If you are writing software specification documents, I recommend that you become as familiar as possible with all of the different types of rich internet application controls and interaction patterns that are examined in detail within these books. Programmers and project and program managers will benefit as well.

A great amount of time and effort will be saved if everyone on the project team has familiarity with these fundamental web interface and interaction patterns. Having a common vocabulary with which to communicate to each other in design and development meetings will pay dividends throughout the course of the software development lifecycle.

The ability to suggest an interaction pattern or a type of control that can preserve screen or page real estate, for instance, can make the critical difference in getting a software system design specified in a limited amount of time. Having knowledge of user interface best practices and common user interaction patterns in-house, on the project team itself, can not only save money in avoidance of expensive user interface consultants and UI design firms, but it can also ensure that the tricky question of post-implementation compliance amongst your development team and programming staff.

I have compiled a list of books that in my opinion merit a place on any professional user interface designer’s bookshelf. If you are looking to stock your User Interface library, you really can’t go wrong with this list of books.

I feel that IT Directors, Product Managers, Program Managers and Project Managers, as well as Graphic Designers, Information Architects, and Interaction Designers and Usability Engineers (read this article if you need help understanding what these job titles mean) could all benefit from reading several or all of these books.

I have found in my professional career that having advanced knowledge of User Interface design techniques and best practices aids me greatly in producing high quality project plans and functional specifications for web based applications and their related software development projects. Mockups and wireframes that incorporate the various design patterns outlined in these books have greatly increased my ability to communicate and develop project related deliverables and artifacts for complex and cutting edge user interfaces, particularly those that include social media platform integrations and RIA, or Rich Internet Application, frontends.

The more knowledge that you acquire in your professional career on a software development team, and the more you know about user interfaces for web based applications, the more value you will be capable of delivering to both your employer and yourself in the form of expanded career opportunities.

Web Form Design: Filling in the Blanks

By Luke Wroblewski. Rosenfeld Media, May 2008.

Web Form Design: Filling in the blanks, by Luke Wroblewski

Anyone who designs anything for the web needs a copy of this. It makes it so nice to not have to think about designing forms. I can spend my time on more interesting design challenges. This book doesn’t leave my desk.

Forms make or break the most crucial online interactions: checkout, registration, and any task requiring information entry. In this book, Luke Wroblewski draws on original research, his considerable experience at Yahoo! and eBay, and the perspectives of many of the field’s leading designers to show you everything you need to know about designing effective and engaging web forms.

I have found this book to be the most practical, comprehensive and data-driven guide for solving form design challenges and I consider it an essential reference.

The Smashing Book #1

https://shop.smashingmagazine.com/smashing-book-intl.html

The Smashing Book #1

This book is available exclusively from Smashing Magazine. This book looks at Web design rules of thumb, color theory, usability guidelines, user interface design, best coding and optimization practices, as well as typography, marketing, branding and exclusive insights from top designers across the globe.

This book contains ten carefully prepared, written and edited stories that are based upon topic suggestions and wishes of Smashing Magazine’s readers. The topics covered here are fundamental and so the content is highly practical.

The Smashing Book #2

https://shop.smashingmagazine.com/smashing-book-2-intl.html#d=smashing-book-2

The Smashing Book #2

This book shares valuable practical insight into design, usability and coding. It provides professional advice for designing mobile applications and building successful e-commerce websites, and it explains common coding mistakes and how to avoid them. You’ll explore the principles of professional design thinking and graphic design and learn how to apply psychology and game theory to create engaging user experiences.

Designing Web Interfaces: Principles and Patterns for Rich Interactions

By Bill Scott & Theresa Neil

Designing Web Interfaces: Principles and Patterns for Rich Interactions

Want to learn how to create great user experiences on today’s web? In this book, UI experts Bill Scott and Theresa Neil present more than 75 design patterns for building great web interfaces that provide interaction. Distilled from the author’s years of experience at Sabre, Yahoo!, and Netflix, these best practices are grouped into six key principles to help you take advantage of the web technologies available today. With an entire section devoted to each design principle, Designing Web Interfaces illustrates many patterns with full-color examples from working websites. If you need to build or renovate a website to be truly interactive, this book will give you the principles for success.

Don’t Make Me Think: A Common Sense Approach to Web Usability, 2nd Edition

by Steve Krug

Don't Make Me Think: A Common Sense Approach to Web Usability, 2nd Edition

Five years and more than 100,000 copies after it was first published, it is very difficult to imagine anyone working in web development or design that has not read this classic on web usability, but people are still discovering it every day. In this second edition, Steve adds three new chapters in the same style as the original: wry and entertaining, yet loaded with insights and practical advice for novice and veteran alike. Don’t be surprised if it completely changes the way you think about web design.

The three new chapters are entitled: Usability as common courtesy (why people really leave web sites), Web accessibility, CSS, and you (making sites usable and accessible), and Help! My boss wants me to ______. (Surviving executive design whims).

In this second edition, Steve adds essential ammunition for those whose bosses, clients, stakeholders, and marketing managers insist on doing the wrong thing. If you design, write, program, own, or manage web sites, you must read this book.

Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems

Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems

It’s been known for years that usability testing can dramatically improve products. But with a typical price tag of $5,000 to $10,000 for a usability consultant to conduct each round of tests, it rarely happens.

In this how-to companion to Don’t Make Me Think: A Common Sense Approach to Web Usability, Steve Krug spells out an approach to usability testing that anyone can easily apply to their own web site, application, or other product. (As he said in Don’t Make Me Think, “It’s not rocket surgery”.)

Information Architecture for the World Wide Web: Designing Large-Scale Web Sites

Information Architecture for the World Wide Web: Designing Large-Scale Web Sites, 3rd Edition

Saul Wurman first used the term Information Architecture in his book of the same name. His book was mostly lots of really pretty pictures of media and webs compiled from a graphic design perspective; they were beautiful but never really dealt with the information end of things. Rosenfeld and Morville get it right. They show how to design manageable sites right the first time, sites built for growth. They discuss ideas of organization, navigation, labeling, searching, research, and conceptual design. This is almost common sense, which is often overlooked in the rush for cascading style sheets and XML.

The Elements of User Experience: User-Centered Design for the Web

The Elements of User Experience: User-Centered Design for the Web

From the moment it was published almost ten years ago, Elements of User Experience became a vital reference for web and interaction designers the world over, and has come to define the core principles of the practice. Now, in this updated, expanded, and full-color new edition, Jesse James Garrett has refined his thinking about the Web, going beyond the desktop to include information that also applies to the sudden proliferation of mobile devices and applications.

Successful interaction design requires more than just creating clean code and sharp graphics. You must also fulfill your strategic objectives while meeting the needs of your users. Even the best content and the most sophisticated technology won’t help you balance those goals without a cohesive, consistent user experience to support it.

With so many issues involved—usability, brand identity, information architecture, interaction design— creating the user experience can be overwhelmingly complex. This new edition of The Elements of User Experience cuts through that complexity with clear explanations and vivid illustrations that focus on ideas rather than tools or techniques. Garrett gives readers the big picture of user experience development, from strategy and requirements to information architecture and visual design.

Forms that Work: Designing Web Forms for Usability

by Caroline Jarrett and Gerry Gaffney

Forms that Work: Designing Web Forms for Usability (Interactive Technologies)

Forms are everywhere on the web – used for registration and communicating, for commerce and government alike. Good forms make for happier customers, better data, and reduced support costs. Bad forms fill your organization’s databases with inaccuracies and duplicates and can cause the loss of potential or current customers. This book isn’t about just colons and choosing the right widgets. It’s about the entire process of making good forms, which has a lot more to do with making sure you’re asking the right questions and in such a way that your users can answer than it does with whether you use a drop-down list or radio buttons.

If your web site includes forms, then you need to read this book. In an easy-to-red format with lots of examples, Caroline Jarrett, who runs the usability consulting company Effortmark Ltd.(http://www.usabilitynews.com), and Gerry Gaffney, who runs the usability consulting company Information & Design Proprietary Ltd.(http://www.uxpod.com), present their three layer model – appearance, conversation, and relationship. You need all three for a successful form – a form that looks good, flows well, asks the right questions in the right way, and most importantly, gets users to fill it out.

Designing good forms is trickier than people think. This book explains exactly how to design great forms for the web. Liberally illustrated with full-color examples, it guides readers through how to define and gather requirements to how to write questions that users will understand and want to answer, as well as how to deal with instructions, progress indicators, and error conditions.

I found that this book provides proven and practical advice that will help designers avoid pitfalls, and produce forms that are aesthetically pleasing, efficient, and cost-effective.

The book is filled with invaluable design methods and tips to help ensure accurate data and satisfied customers, and includes dozens of examples, from nitty-gritty details (label alignment, mandatory fields) to visual design (creating good grids, use of color).

Defensive Design for the Web: How to improve error messages, help, forms, and other crisis points

Defensive Design for the Web: How to improve error messages, help, forms, and other crisis points

by Matthew Linderman and Jason Fried

Let the 37signals team show you the best way to prevent your customers from making mistakes, and help them recover for errors if a mistake does occur. This book doesn’t leave my desk either.

The folks at 37signals have created an invaluable resource: tons of ‘best practice’ examples for ensuring that web users can recover gracefully when things – as they inevitably will – go ‘worng’ !

In this book, you will learn 40 guidelines to prevent errors and rescue customers if a breakdown does occur. You will see hundreds of real-world examples from companies like Amazon and Google that show the right (and wrong) ways to handle crisis points.

You can also use this book to evaluate your own site’s defensive design with an easy-to-perform test and find out how to improve your site over the long term.

About Face 3: The Essentials of Interaction Design

By Alan Cooper. Wiley 2007.

About Face 3, by Alan Cooper

Learn the rules before you break them. Please. Pretty please with a cherry on top? Get this book and read it if you are responsible for designing anything more than a simple web site. Good for Flex developers and Ajax developers as well. Lots of patterns that can be extrapolated for Rich Internet Applications.

Prototyping: A Practitioner’s Guide

Prototyping: A Practitioner's Guide

Prototyping: A Practitioner’s Guide” is a terrific and comprehensive review of both the prototyping process and the tools involved. There’s really very little with which to find fault. I found that the book both validated my experience in prototyping and provided new techniques to try out, with many “Aha!” moments in both respects. The inclusion of case studies illustrating the techniques provide additional perspective and make the techniques more “real”. The review of each prototyping technique/tool, whether paper or software-based, includes links to additional resources like toolkits, sample images, and the like – these would be especially useful to someone just getting started with a particular tool. Speaking as a designer who’s typically relied on HTML prototypes and Visio, I must say my interest in Adobe Fireworks and, to a lesser extent, Axure is piqued. I think any UI/UX/IX designer, of any level of experience, would get something out of this book. Not that it would be useful only to them – analysts and software engineers will benefit from it as well.

Want to know more?

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. I have been working in the software engineering and ecommerce industries for over fifteen years. My interests include computers, electronics, robotics and programmable microcontrollers, and I am an avid outdoorsman and guitar player. You can connect with me on LinkedIn, follow me on Twitter, follow me on Quora, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m a Technical PMO Director, I’m a serial entrepreneur and the co-founder of several ecommerce and web-based software startups, the latest of which are Twitterminers.com and Tshirtnow.net.

What is a Product Roadmap? What is an Engineering Roadmap? July 21, 2011

Posted by hubtechinsider in Agile Software Development, Project Management, Uncategorized.
Tags: Agile Software Development, Microsoft Visio, product management, product roadmap, Project Management, Software Development, Software Engineering, Technology roadmap
2 comments

English: Five-Year Technology Roadmap (Photo credit: Wikipedia)

What is a Product Roadmap? What is an Engineering Roadmap?

Product roadmaps can provide an organization, particularly a software development one, with the critical difference between success and failure when marketing and delivering software, services, or products to the marketplace.

While normally the purview of a product manager or director, another senior manager (project, program) or executive can also be charged with preparing and presenting a product or engineering roadmap, and when prepared properly, they can be extremely effective.

The benefits of roadmaps can include retention of key customers, business and channel partners, and engineering and product roadmaps can ably guide the strategic planning and engineering efforts of a company.

As amazing it may sound, I have frequently encountered, within the development organizations I have worked at within the Boston area, a lack of types of artifacts I am about to describe. The lack of product and engineering roadmaps that are accessible to viewers, easy for presenters to use in their slide decks and demos, and visually compelling enough and understandable enough so that audiences can grip the feature sets and timelines shown to them is a major cause of planning and project failure.

It is easy to visualize, once we have gone into a bit more detail regarding the different types of product and engineering roadmaps, how project and product planning attempts at companies without these types of deliverables (or the in-house skillset required to even prepare such artifacts) fail miserably. Computer programmers are not the best resources, in general, to call upon to produce these types of artifacts, nor are engineers who have been promoted to management positions. Typically the best preparers of roadmap documents will be from the business or management world, or have a diverse skillset that may be based in engineering, but you definitely need people who can generate business documents quickly and effectively.

Having folks that are knowledgable and skilled with graphic design programs like adobe photoshop, Illustrator, and microsoft visio can speed the roadmap creation process tremendously. When you have found the right internal resource or team to create these roadmap documents, you will know it, as the right people will already possess some amount of experience with roadmap and business strategy content creation.

It is not enough, please keep in mind, for a company to “short shift” the production of these roadmap documents, because it is only through the repeated creation of roadmap documents, and through their constant updating and presenting to audiences internal and external, will your organization be able to increase its ability to produce roadmap documents quickly.

A complete catalog of engineering and product roadmap documents should be created: eventually. If your company cannot mount such a concerted document creation efforts due to staffing concerns, just create what you can. Cherry pick the type of roadmap document you think would create the most value for your own organizational requirements from my detailed list below.

An example of a roadmap from Microsoft

It could very well be that your organization’s needs for a roadmap document are clouded by the sales department or company management demanding an engineering or product roadmap (sometimes in support of sales efforts) under-the-gun. Never fear: I have not only provided the information you need, I have lots of examples and pictures of product and engineering roadmaps as well as Microsoft visio and excel templates for simple and complex roadmap documents. You can use these microsoft excel product roadmap template and microsoft visio product roadmap templates to create your product or engineering roadmap quickly, avoiding trouble just when you’re getting started.

If you are a product management professional, and you are tasked with the responsibility for the ultimate success of a product line or engineering effort for your company, it is of paramount importance that you produce a roadmap document that can drive strategy, provide a clear idea of where you are headed with your efforts or product(s), and can be shared easily with internal and external stakeholders and business partners and analysts, even the press.

A product or engineering roadmap document may be appropriate when you are called upon to support a pre-sales or sales effort for your organization. Demos, presentations, press releases, investor and business meetings are all very good occasions for product or engineering roadmaps to assure clients, partners, and employees that there is a consistent and cogent plan of action and guide for resource planning and engineering efforts.

There is a wide variety of different names and definitions for all manner of roadmap documents. The important principle to adhere to is you should find and adapt the type of roadmap document you are comfortable with and that you find works for you.

What are the different types of product roadmaps? What are the different types of engineering roadmaps?

Speaking generally, there are five major types of roadmap documents: Product roadmaps, platform roadmaps, market roadmaps, strategic roadmaps, vision roadmaps, and technology or engineering roadmaps. You can, of course, mix and match these roadmap types to suit your organization’s needs.

How do you create a product roadmap? How do you create an engineering roadmap?

There are eight steps I always follow when I am asked to create each of these types of roadmap documents – you can mix this list of steps with your own ideas and experiences in creating roadmap documents:

1. Decide upon which type of roadmap document you will use based on your individual requirement for a roadmap document.

2. Think about how much time and effort, as well as level of detail, you think will be required for you to invest, or that you care to invest, in the creation of your chosen roadmap document type.

3. Brainstorm about significant forces or trends that you might want to represent on your roadmap document. These could include technical breakthroughs, market forces, and moves the competition has made recently.

4. Elicitate the precise roadmap document requirements from the primary internal stakeholders in the project, and document and prioritize those requirements, being careful to estalish and maintain traceability.

5. Product Roadmap documents are intrinsically linked with time, so think about the timeline you want to use and represent in your document.

6. Think about the impression your strategy will make and how you want to present that strategy in your roadmap document. This is one of the central purposes of the document you are preparing, to show that you have a strategy and are planning to implement it well and to schedule.

7. Sometimes I create an internal roadmap document and distribute it to the primary internal stakeholders within my organization for review and commentary. After gathering the project team’s comments regarding the internal roadmap, there is a good basis on which to draft the external roadmap document.

8. This colloborative approach is critical to obtaining buy-in from senior management as well as the roadmap document project team. This method also prevents surprises and last-minute revisions. Discussions surrounding the creation of roadmap documents can help solidify the company’s direction and clarify the intents of management to employees very effectively.

Prioritizing product and engineering roadmap features

There are probably potentially many features you could choose to highlight as a part of your product or engineering roadmap document. But in the interests of brevity and clarity, you will need to prioritize the features that are included in each of your upcoming product or service introductions or software releases and shown on your roadmap.

I have always found that a prioritization matrix document is the best bet for effective and colloborative feature selection for inclusion in a roadmap document. Microsoft Excel or another computer spreadsheet program works very well for preparing this type of document. The matrix should hold information regarding such components as startegic importance, tactical importance to the current release cycle, customer desireability level, retain revenue threat from customer dissatisfaction, revenue impact, source and date of the feature, planned release, etc.

Themes can be used to categorize major feature trends that you begin to see emerge from your prioritization matrix. Categorize like features into themes and then select one or a few major themes to represent graphically on your roadmap documents.

Timed release cycles use the timescale along the edge of your roadmap document to show when features will become available. This type of roadmap document is driven by time and not by features. Once the release interval is decided upon, then the feature list is divided up amongst the releases those features are planned to become available with.

The golden feature technique is one where each release is governed mainly by one important or central feature. Once you have selcted the golden feature for each release of a product or service that you are attempting to show on your roadmap document, then you will be able to focus the audience’s attention on that one feature, and highlight it in all your continued planning efforts for that release.

Using multiple roadmap documents

Combining a few or several different types of roadmap documents can greatly enhance your presentation, showing that you know where your company is headed and why it is that you have choosen to pursue a certain strategy. A vision roadmap could be used to open your presentation, showing trends in society at large that are afecting your marketplace. A technology roadmap could then be shown to your audience that reflects how your company and it’s products are capitalizing on technology trends within the marketplace. Then it is time for you to show off your internal and external product roadmaps, and perhaps your engineering roadmap that shows your planned releases and when certain feature sets will become available.

Showing multiple product lines on roadmap documents

You may need to show a few or several of your product lines on a roadmap, in order to visually represent how each of your product lines will evolve in accordance with a technology or marketplace trend. This is very easy to accomplish; simply create a roadmap document for one of your product lines or services,and then use that one product line as a template for showing the others on your single roadmap document.

I have found that it is helpful in many cases to create a prioritization matrix such as the one I mentioned elsewhere in this article regarding features to show on your roadmap documents. You can also create a product line prioritization matrix that can be used for discussion and colloboration with your internal stakeholders.

A product roadmap showcasing multiple product lines

Try and decide upon which projects, products, or services your company is undertaking that are the most important to your company, which ones should be funded and resourced, and which ones should be cut. Revenue potential, market positioning, strategic importance to the company, and interdependencies can and should be plotted out on this matrix. Once you have decided which products you want to represent on your roadmap document, it is a simple matter to modify your format to include multiple product lines on a single roadmap.

Five tips for creating product roadmaps

Here are a few more best practices that I have discovered throughout my career of preparing product roadmap documents.

It is essential that you realize from the outset that when working with a technical (programmer) audience in certain working environments, there may be a fair bit of resistance or friction originating within internal departments or product groups at your own company that you will need to overcome.

Many internal stakeholders may take umbrage at the point in the release cycle that certain features are slated for release on your roadmap document, they may assert strongly or even rudely that your presentation is false or feature sets you are publicly committing to will not be available.

It is important for you to always be ready to provide reasoning why the roadmaps are necessary, and why managing without such documents, at certain levels of business, becomes untenable.

1. Make sure that you colloborate early with your team. Your chances of being able to secure ultimate buy-in from the different internal constiuency groups within your company goes up markedly if they have been included from the roadmap document project’s outset.

2. Always use code names on your roadmap documents until they have been approved by the senior management team for release to the public at large. You cannot be sure that your roadmap documents will not be leaked out, even by senior managers. You can revise the code names to final product and project names when they are approved.

3. Minor releases and localized, international releases are sometimes not shown on product or engineering roadmaps, and they should be included, as they frequently enter into the follow-on conversations.

4. Create roadmap documents for an internal audience that are very specific in information and dates; roadmap documents intended for an external audience should be worded in more vague language and terminology.

5. Present your roadmap documents as uneditable adobe .pdf documents — this will prevent other parties internal to your company from taking the roadmap documents and altering them – these alterations can emerge unpleasantly later during the project(s) as a committment made to a client or customer by a senior manager or executive, so take care to avoid this scenario.

Examples of internal and external roadmap documents

Product roadmaps

Microsoft SQL server product roadmap

If you need to show your audience when your product’s new features will be available, what the theme or main and secondary features of the product release or next few releases will be, then an effective product roadmap should be your tool of choice.

Internal product roadmaps can be used to communicate budget, resource planning, project priority, and release planning to employees and department heads. They are extremely effective for driving efforts to obtain funding from senior management or corporate action committees.

An example of a product roadmap

External product roadmaps can be used to support funding efforts from investors or investment groups, business partner meetings. External product roadmap documents and slides can be used to reinforce public press releases and press conferences, analyst meetings and conference calls or webcasts, clients and channel partner webinars. It is oftentimes apparent that external roadmaps have been recast in a more vague tone as a result of internal roadmap feedback, which is generally a good thing.

Platform roadmaps

A platform roadmap

A platform roadmap is used to showcase what will be n the works for the platform or PaaS (Platform as a Service) that a particular company has under development. They are used to communicate that company’s overall platform strategy and the availability of APIs (Application Programming Interfaces, basically plug-ins to amd from the company’s platform software) and development tools for the company’s platform or PaaS.

If a company has developed and is supporting a platform in the marketplace currently, you can be sure that they have a platform strategy that relies on partners and clients working closely with them. The need to communicate the platform’s strategy in a clear and focused manner is very important. Examples of platforms include Salesforce.com (Force.com), Windoes (Windows Azure Cloud), Amazon S3 and Ec2, Google, Apple Mac OS X, Apple iOS, Hp WebOS, and many others.

Vision roadmaps

A vision roadmap example

There are times when at the onset of a demo or presentation, it is necessary to highlight for your audience how your product or products fit into a movement or trend within society in general or your company’s inductry in particular. This is a fantastic way in which you can build excitement and marketplace momentum for your company’s products or services by visually demonstrating how you fit into the big picture.

Marketing roadmaps

Microsoft Windows OS roadmap

A marketing roadmap communicates to your internal and external stakeholders what market segements your products and services are targeting, and how you plan to enter any of those markets in which you are not currently competing. As such, these types of roadmaps include information on the demographics and opportunity size of each marketplace, and information regarding how you plan to develop products and services to address each market. The timescale involved on marketing roadmaps can span years.

Marketing roadmap example

A marketing & strategy roadmap

Technology and Engineering Roadmaps

Technology and engineering roadmaps chart out major technology trends that exist in the marketplace, and show how your company’s products and services coordinate with those trends over time. Engineering roadmap documents are used to communicate feature sets that will be available in certain releases. The approximate release dates of each of the company’s upcoming product releases will be shown.

A technology roadmap

It is very common for a software development organization to create and maintain multiple engineering roadmaps, suitable for showing to various segmented audiences of internal and external stakeholders and directly responsible individuals. These engineering roadmaps are super tools for updating major clients and customers of your release cycle and aid greatly in the change management process.

A Microsoft Technology Roadmap

Engineering roadmaps also provide your internal development groups, qa, testers, programmers, business analysts, and product, program and project managers, as well as senior management, with a view into the development life of the company. A development organization that fails to produce such planning artifacts is essentially flying blind, and as they scale up (if they do scale up) as their business improves, they will find they lack the requisite skills needed to plan effectively and manage their clients’ expectations for quality products, software and services well.

Product roadmap template

Engineering roadmap template

I have included in this article many pictures and descriptions that you can use to create your own highly compelling product roadmap documents. They should serve as an excellent guide for not only the different types of roadmap documents that exist out here in the marketplace, but also how to place multiple product lines and services on a roadmap document.

Keep in mind, these are living documents, and should be continuously maintained and updated. Do not succumb to the programmer’s maxim “You can’t plan the future”. Remember: Plans are worthless, planning is priceless. The activity of creation, the discussion that surround the roadmap process, are all essentially components of effective long term product planning and corporate strategy.

Roadmaps can be used to share information with internal teams, external constituents or as a planning tool for the Product Management team, but whichever you choose, you have to figure out whether you are going to make the focus of the roadmap strategy or release calendar. If it is strategy, your timeline can be vague — quarters or years. If it’s release calendar, the near-term has to be pretty specific: exact date or month, but the future can be more nebulous.

I have include a few simple microsoft visio and microsoft excel roadmap document templates to get you started. By all means, you should feel free to use the illustrations and prose contained in this article, as well as any graphics or business drawing tools that you are comfortable with, to create your own formats and presentations. Some of my favorite programs for creating these types of artifacts with include adobe illustrator, photoshop, microsoft visio, microsoft excel, and coreldraw. I also have a big bag of Linux and Apple Mac OS X tools that I use to create roadmap documents in addition to the ones I have just mentioned. Product management software such as Accept, Accompa, FeaturePlan, FocalPoint and others can also assist you in creating roadmap documents. If you need help or advice, I am always available via email or social media like LinkedIn. If we’re not connected on LinkedIn, please send me an invitation to connect. And good luck with your roadmaps!

roadmap_template1

SvN Flashback: Product roadmaps are dangerous (37signals.com)
The Start-Up Drive : Startups need planning. (dannedelko.com)

Want to know more?

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, follow me on Quora, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m a PMO Director, I’m a serial entrepreneur and the co-founder of several ecommerce and web-based software startups, the latest of which is Tshirtnow.net.

JavaScript required to play paul_seibert_hubtechinsider_introduction_HD_rev1.

Needham’s Sonian, a provider of email archiving solutions, raises $4 Million December 20, 2010

Posted by hubtechinsider in Uncategorized.
Tags: Business, E-mail archiving, Electronic discovery, Microsoft Exchange Server, Needham, Needham Massachusetts, Novell GroupWise, Prism VentureWorks, startup, Startup company, Venture Capital
add a comment

Needham’s Sonian, a provider of email archiving solutions, raises $4 Million from a group of investors including Prism VentureWorks and Summerhill Venture Partners.

Sonian Pulls In $4M (xconomy.com)
Sonasoft’s Efficient eDiscovery Solution for Email Archiving Optimizes Searches While Reducing Discovery Costs (prweb.com)
Sorting Through E-mail Archiving Tools (pcworld.com)

Wilbraham MA based FloDesign Wind Turbines prototypes are 3 times more efficient than 3 bladed windmills October 30, 2009

Posted by hubtechinsider in green technology, renewable energy, Uncategorized, Venture Capital.
Tags: Green Energy, green technology, renewable energy, Venture Capital
add a comment

Using design features borrowed from jet engine design, Wilbraham, MA -based FloDesign Wind Turbine has produced prototypes capable of producing electricity three times more efficiently than conventional, three-bladed wind mill designs.

In FloDesign’s prototype, two concentric hoops channel air into patterns that create spinning vortexes – like minature tornadoes – as the exiting air passes the turbine blades, dramatically boosting air flow.

Wilbraham, MA's Flodesign Wind Turbines

Unlike conventional windwills, FloDesign’s model can be transported on one truck, compared with three trucks for conventional wind mills. The new design can produce electricity at lower wind speeds and in the midst of more volatile wind gusts, making it a shoo-in for spots – like beaches and cities – that have until now been inhospitable for wind power generation.

Silicon Valley Venture Capital firm Kleiner, Perkins, Caulfield and Byers committed $6 million to the company in 2008. The company also has raised funds from the U.S. Department of energy and hopes to raise an additional $25 million later this year.

Waltham MA based Inverness Medical Innovation Systems acquires Seattle based Free & Clear for around $130 Million October 29, 2009

Posted by hubtechinsider in Health Care IT, Uncategorized, Venture Capital.
Tags: Venture Capital, waltham
add a comment

Waltham, MA-based Inverness Medical Innovations (NYSE: IMA) has acquired Seattle-based Free & Clear for $100 million in cash, plus up to $30 million in potential follow-on payments based on Free & Clear’s 2010 revenues. Inverness Medical Innovations manufactures consumer diagnostic tests such as pregnancy tests, and also provides wellness and disease management (DM) services through its Alere subsidiary. Free & Clear, which was backed by Waltham, MA -based Polaris Venture Partners, Three Arch Partners, and Kaiser Permanente Ventures, offers telephone-based coaching for company employees battling tobacco addiction, obesity, and stress.

The Twenty Laws of Testing Computer Software September 24, 2009

Posted by hubtechinsider in Agile Software Development, Project Management, Technology, Uncategorized.
Tags: Agile Software Development, developers, product management, Project Management, Software, Software Development
4 comments

As a software development project manager, I conduct, plan, organize and cajole the software engineering efforts in companies large and small. During the course of this work, I have never ceased to be amazed at the lack of understanding of both the importance of properly testing a software product or products, and the lack of knowledge around how to correctly conduct the testing effort.

This holds true in corporations both large and small that I have worked for during my fifteen year professional career. In my opinion, a Project Manager should have a complete understanding of the software testing process, and should also have experience not just scheduling and planning the resources conducting the testing effort, but actual personal testing experience.

It occurred to me earlier on in my career as a Project Manager that in order for me to be a better Project Manager, I was going to have to learn and research everything I could get my hands on about testing computer software. I took courses, I bought books and read them; I related the information I gathered to my experiences as a developer and in some of the ecommerce companies I had worked for and built early on in my career.

I found that this desire to learn the ins and outs of testing was over half the battle towards becoming a more accomplished PM. The Project Manager who appreciates the importance of testing, has been a tester, knows and respects the testers on the team, and has a deep seated, fundamental respect for testing is a Project Manager who commands respect from his project team.

One of my favorite books is “Microsoft Secrets”, by Michael Cusomano. In the book, he describes how early on in the history of the company, testing became a career path on the same level as programming. Knowing, from my extensive reading about Microsoft and Bill Gates, the high altar upon which programmers are placed at Microsoft, I found this to be extremely significant.

Great software development teams and great software engineering companies take the testing of their software seriously. They don’t cut corners, and they don’t have to, because they began with the end in mind.

So without much further adieu, here are my twenty laws for testing computer software. Look for me to expound upon each of the twenty laws in more detail on these pages very soon:

The sole goal of testing software is to find errors. Software testing is defined as the method of running a computer software program with the intent of discovering errors in the computer software program.

The definition of a good test case is that a good test case is one that has been written in such a manner that it has a great chance of discovery of previously undiscovered errors.

A successful test case is one that has been used to discover a previously undiscovered error.

Only a high quality software testing process will result in a high quality software testing effort.

Testing computer software is a professional discipline that must include skilled and trained professional computer software testers.

Someone must assume full responsibility for the improvement of the software testing process.

It is vital to foster a 100% positive, inclusive and team-oriented approach with a “test to break” mental attitude.

A test case for testing a computer software program must include a definition of the expected result of the computer software program being tested.

A computer software programmer should not test the computer software program they have coded themselves.

By extension, a computer software programming organization or engineering department should not test its own programs; This is the work of an independent testing organization.

The results of each test case should be reviewed with great care.

Test cases should be written in order to include unforeseen and invalid user inputs, as well as foreseen, valid user input.

Testing a computer software program to insure it performs as it should is only fifty percent of the testing effort. Another fifty percent of the testing effort should be expended in order to insure that the computer software program does not perform in ways in which it should not be performing.

Avoid one-time, spontaneous, disposable test cases.

A testing effort initiated under the assumption that no errors will be found will not be a successful computer software testing effort.

The proliferation of errors in a computer software program can be prevented through the employment of testing during the early stages of the software development lifecycle.

Software testing tools can be and should be a key element of a software testing effort.

Although perhaps counterintuitive, the probability that more errors will be found in a section of a computer software program in which errors have already been found increases with the number of errors discovered in that section of the computer software program.

Testing computer software well is an extremely mentally challenging exercise that requires creativity and perseverance from the testers in order to succeed.

The perception (oftentimes forwarded by management) that “not enough time exists to test the product properly, so let’s just ship it anyway”, because the “rewards of shipping the software outweigh the risks of shipping the software with undiscovered errors” may still be common practice in many software development and engineering organizations, yet such an attitude will lead to catastrophe, as software quality is intrinsically linked to customer requirements and customer satisfaction.

Want to know more?

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m the Director, Technical Projects at eSpendWise, I’m a serial entrepreneur and the co-founder of Tshirtnow.net.

Eight ways to tell if your project team is on the way up or on the way down June 21, 2009

Posted by hubtechinsider in Project Management, Uncategorized.
Tags: Agile Software Development, product management, Project Management, Software Development
2 comments

In my professional roles leading software development teams, I have found that how Project Managers interact with their project team says not only alot about them as leaders, but also speaks volumes about the state of the organization itself. There is a dynamic lifeblood of personal relationships and interactions at the heart of a software development team that is an interesting take on leadership and team behavior. Your project team is either on the way up, or it is on the way down. In like fashion, your organization is either on the way up, or it is on the way down. Not every sign is easily recognizable at the time for what it really represents in terms of the direction your project team is heading.

A project team and an organization’s decline is like a disease: it is harder to detect but easier to cure in the early stages, and easier to detect but harder to cure in the later stages. Your project team and the encompassing organization may appear to be strong on the outside, but savvy insiders may be able to comprehend that your team is on the cusp of a dangerous and fatal fall off the cliff.

I have had the benefit (as I view it; Some would say curse) of having watched project teams in several different organizations and multiple industries. But it was easy to write about the below eight indicators because the signs tend to be the same regardless of the company and industry. In my role, you need to foster the good kind of environment where your project team can feel that the individuals are gelled into a cohesive unit that is winning. This feeling, rarely experienced, is like magic, and when a project team is hitting on all cylinders, each individual is capable of contributing their best to the endeavor at hand and feels like they are part of something special. Do your best as a Project Manager or team leader to foster this type of environment. Watch closely the eight key performance indicators I write about below and see how your current (or past) project teams have reflected which direction they are / were traveling in. You are either on the way up, or you are on the way down.

1. How is reality faced? – A team on the way down will shield the business owner or project sponsor from unpleasant facts – fearful and trepidacious, expecting criticism and penalties as a result of exposing rough realities. A team on the way up will constantly be exposing harsh realities: “Hey, man, look at this — this sucks hard…we got to fix this, and now”. Team members of a team on the way up will always bring forth these types of facts, as their project manager / team leader will never be critical of those who bring these ugly facts to life, feeling they need to be discussed and rectified.

2. How do project team members assert and support their opinions? – In a team on the way down, project team members will assert their opinions strongly, but will not provide data or evidence needed to form a strong and compelling argument. In a team on the way up, team members readily offer up solid data, evidence and bring logical argumentation skills to the discussion.

3. What style does the Project Manager use? – If the Project Manager or Project team leader uses a very low questions-to-statements ratio, and avoids critical input and allows sloppy reasoning and unsupported personal opinions to circulate in meetings, then your team is probably on the way down. However, if your PM or leader employs a Socratic style, using a high questions-to-statements ratio, challenges people and pushes for penetrating insights, then your team is probably on the way up.

4. How does the team coalesce behind decisions? – If team members grudgingly acquiesce to a decision but do not unify behind it or even work behind the scenes to undermine the decision ex post facto, then your team is on the way down. Teams on the way up will unify behind a decision once it is made, and work to make it successful, even if they did not initially agree with it.

5. How does the team give credit to each other? – Teams on the way down will seek as much credit for their own part of the job as possible for themselves, often not even noticing that this style seldom results in the confidence and admiration of their peers. In a team on the way up, project team members will credit others for success, and they find that this tendency will result in the admiration of and confidence from the other project team members.

6. Do team members need to look smart in front of each other? – In a team on the way up, project team members will argue to look smart or to further their own particular interests within the organization, but in a team on the way up, team members’ arguments and debates are all geared towards finding the very best answers to the problems and issues the project team is facing. Nobody worries about “Looking smart” in a team on the way up, because they have internalized that old saying: “Being smart’s alot like being ladylike: if you have to say you are, you probably aren’t”. Nobody in the team on the way up wants to look cool – they want to be cool.

7. Does the team conduct ‘post-mortems’, and how? – In a project team on the way down, culprits are sought for blame rather than in a team on the way up, where autoposies are conducted in order to mine wisdom and learning for the next time around or to make sure that the misstep results in a learning experience. Otherwise, a mistake is a mistake made twice. Project teams on the way up don’t have time to blame team members – they are too busy moving forward with the next items of business.

8. How about results? – Teams on the way down, unsurprisingly, often fail to deliver great or even good results. They spend alot of time blaming either individual team members or outside factors for setbacks and failures. A team on the way up, in contrast, is comprised of individual team members who are all delivering exceptional results, but in the case of mistakes, setbacks, and errors, each team member accepts full responsibility on their own and learns from the mistakes. The project team on the way up fosters this environment which enables each individual team member to feel comfortable doing so.

Want to know more?

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, even friend me on Facebook if you’re cool. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m the Senior Technical Project Manager at eSpendWise, I’m a serial entrepreneur and the co-founder of Tshirtnow.net.

Five tips for recruiters on contacting potential job candidates in a tough job market June 15, 2009

Posted by hubtechinsider in Staffing & Recruiting, Uncategorized.
Tags: human resources, recruiting, staffing
4 comments

I have been on both sides of the fence when it comes to job interviews — for the two ecommerce software companies I started back in the 1990′s, I hired hundreds of people, so I talked to alot of staffing firms and recruiters. In my current life as an IT Project Manager / Business Analyst / Program Manager, I have not only taken on a few contract roles in the Boston area myself, but I have also been tasked at various times with hiring other contractors to work on large software development projects. In all these roles, I have been in contact with staffing firms, agencies, and corporate recruiters that are not very good at their job. Many of the recruiters out there are great, but the majority are not great. After reading yet another drivel and platitude filled article about recruiters and “how to get a job” from the Boston Globe today, I thought it was high time for an article with some real-world tips and practical advice for recruiters on how to contact candidates out there in the midst of a tough job market. I found after writing these five tips for recruiters, however, that they are applicable in any economy. These five tips are fundamental imperatives for all recruiters to read, know and internalize so that they do not destroy their professional reputations and ruin the reputations of their staffing firms and employment agencies.

1. Do your homework on candidates before picking up the telephone – If you don’t have any jobs for a candidate, don’t call them up on the telephone. If a candidate is not a good fit for your particular search, then they are not going to be interested in hearing from you: think about it. Just because someone is a candidate and is out there looking for work, doesn’t mean they are going to be thrilled to talk to a recruiter on the telephone. They will really be perturbed at you when they realize that after an initial contact, you didn’t look at their resume or their Linkedin profile or really perform any homework on them until you get them on the telephone – only to tell them they aren’t a good fit, not what you’re looking for or you don’t have any jobs for them. You should have never called them on the telephone in the first place. Lazy recruiters are all too common these days, and nobody wants to hear whining about time constraints, number of candidates, or the rest of it. Get on LinkedIn, read the profiles of your candidates, and carefully read their resume. In this way, you can be ready to ask purposeful leading questions such as “So I read about your experiences with the Executive Dashboard application at Metatech; I know you wrote on your resume that it was an Oracle project, but I’m wondering if that was a .net or a J2EE environment. Can you tell me a little more about it?”… this is a great way to get the information you need from a candidate and it prevents you from looking like a brainless recruitron. If you are a recruiter and you are not on Linkedin yourself, the message you are sending out is that you are not a veteran, serious, professional recruiter, and you are, in fact, recruiter that has something to hide and should not be trusted. When you do get a potential candidate on the telephone, announce yourself with politeness: “Hi, this is Wendy Sprague from Recruit-Tech, and I’d like to speak with Susan Holmes if she is there please” is a great way to reach Susan about a potential job opportunity. “Hi, is this Susan?” is an example of a bad way to begin such a sourcing call. Be polite on the telephone! Do your homework on the candidates!

2. Don’t be rude on the telephone with potential candidates – The internet is a two-way street. In other words, people can write about you and your company / staffing agency / firm online. And they will. I started a few ecommerce companies in college. I used to tell my employees: “If someone has a great ordering or retail experience with us, they will tell two of their best friends – if they have a bad experience they will tell ten or fifteen people right away”. Not doing your homework on candidates before getting them on the telephone, wasting their time on the telephone, rudeness, insulting people’s backgrounds or resumes because they aren’t the pink unicorn you are currently searching for, cutting people off, telling them they “aren’t the right fit” when you should have been able to tell that before calling them up, etc. is going to work out badly for you in the long run. A candidate is just one person. A company is exposed to the public and a corporate reputation for rudeness and incompetence is alot harder to overcome than a single, individual’s reputation. In essence, a staffing firm is a very visible public entity and word gets around. Don’t forget: contractors talk to each other and to the clients once they are in the client company. Many are eventually hired permanently and even ones who remain contractors are often tasked with hiring other contractors. Remember this the next time you are speaking on the telephone with a candidate, because they will surely remember you.

3. Your candidates’ professional references are not marketing contacts – A typical ploy in the tough current Boston IT contract market is to call in job candidates for an in-person interview on the pretext of some nonexistent job or some vaguely-defined future contract. Then, in this challenging market for staffing firms, the account managers are tasked with getting the candidates to “Drop the cheese” and the candidate is then grilled for marketing information for the staffing agency or firm. Manager’s names at former employers, managers at the current employer, etc. are all gathered. Then, a bogus in-person “reference check” is set up. The staffing firm then essentially “calls in” the favor of an in-person reference check using the candidate’s name – to try and drum up new business for the staffing firm at the candidate’s former or current employer. Your candidate’s professional references are not marketing material for your staffing firm. What is likely to happen is the manager will call up or email the candidate and tell them about this marketing meeting, and that staffing firm will never get any future business from the candidate’s former employer. Again, people talk in this new age of social media and online blog posts. So don’t do it. Your candidate’s professional references and work history is not an opportunity for your staffing firm to “get in the door”. If you use these disingenuous methods, it will be exposed in public and also behind closed doors at the offices of your potential clients – not to mention all the contractors and potential candidates that will turn up their noses in disgust at the infinite re-telling of the story. Staffing firms have alot of competition, and there are so many other firms to go with — don’t accept this high level of business risk.

4. Don’t wear out your candidates’ professional references – Get the candidates professional references and then ask the permission of the candidate to call them. Don’t call them before you have a definite REQ for the candidate and they are indeed a primary candidate for the job. The reason for this is simple: professional references are usually busy people and it is not their job to give detailed references for former employees. It is a difficult and tense thing for managers to do even for people and former employees who were superstars and well liked. Most managers will give a candidate one or two really good references, but by the time they are called for a third or fourth reference, they are either not giving them or not giving good ones anymore. So don’t wear out the professional references of your candidates! Again, this is another point of which I must emphasize that word gets around – quickly in this world of blogs, twitter, and such.

5. Have integrity and follow-through – If you only have one job REQ (or no REQ) for a candidate, if you tell them your firm has lots of potential jobs for their title and role, which you don’t follow up on with the candidate, they will tell everyone they know that you and your staffing agency / firm lied to them. Eventually, they will get hired, but they won’t ever forget that you lied to them – why place an enemy in so many potential client firms? In matters of personal livelihood, people in general have long memories. So don’t think they forgot about all the jobs for them you told them about. To come and meet with you in your office, most candidates will have to use up a sick day or miss a day of work. So you better get down to business with your candidates quickly. To lie about these types of matters is not harmless to the job candidate, and it’s not harmless to the business of the staffing firm or agency, let alone your personal professional reputation. Again, don’t do it.

A good article I found online that makes some great points about hiring in a down economy is available here, and I recommend it highly.

What is “management by walking around”? June 13, 2009

Posted by hubtechinsider in Agile Software Development, Management, Project Management, Uncategorized.
Tags: Agile Software Development, Management, product management, Project Management, Software, Software Development
4 comments

Sometimes also called “Management by walking around” or MBWA, management by sight is a management strategy that can and should be integrated into any management style or approach. It is very people-oriented and it requires managers to be visible and interact heavily with project team members. Interactions at all levels of the project team foster the quick and efficient gathering of information about the project and the project team members.

Management by sight is very direct and the manager practicing it utilizes observation and visibility to conduct project analysis and project leadership, to monitor the situation, and to provide control when necessary.

I have had a great amount of success using this management technique and I thought I would share with you twelve guidelines for MBWA which were shared with me by @sjohnson717 on Twitter in response to this original MBWA post. These tips are great and I recommend following them when using this very simple and effective management technique.

Simple and effective management techniques are what every manager needs more of these days!

Want to know more?

About the author.

management, mbwa, management by walking around, it management, it, information technology, project management

What is an ACNA? What is a CCNA code in telecommunications? June 8, 2009

Posted by hubtechinsider in Definitions, Fiber Optics, Telecommunications, Uncategorized.
Tags: CCNA, Competitive local exchange carrier, InterExchange Carrier, Paul Seibert, Telecommunications
add a comment

An ACNA stands for Access Customer Name Abbreviation; It is a three-digit alpha code assigned to identify carriers, both ILECs (Incumbent Local Exchange Carriers) and CLECs (Competitive Local Exchange Carriers), for billing and other identification purposes.

It is closely related to the CCNA code, or the Customer Carrier Name Abbreviation, which identifies the common language code for the IXC (InterExchange Carrier) providing the interLATA facility.

The CCNA reflects the code to be contacted for provisioning whereas the ACNA reflects the IXC to be billed for the service.

Want to know more?

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m the Senior Technical Project Manager at eSpendWise, I’m a serial entrepreneur and the co-founder of Tshirtnow.net.

Demandware gets Round D funding of $15MM and works to answer SaaS ecommerce challenges, under incredible marketplace pressures May 23, 2009

Posted by hubtechinsider in Ecommerce, Uncategorized, Venture Capital.
Tags: demandware, ecommerce, SaaS, Venture Capital
5 comments

Recently I tweeted about Demandware (Woburn, MA) not getting their Round D funding – this was incorrect, and I have retracted this information. The link to the $15 million Form D filing with the SEC is here

[There were rounds of layoffs at Demandware around spring 2009, just prior to this Round D. Round D is generally the last round of financing before an IPO. Many of their employees in Woburn, Massachusetts were laid off. Interesting move. Without this $15 million, it was unclear to many outside observers how strong Demandware's cash position would have been. Take care to distinguish between "brands" and actual "accounts". Demandware has lost some high profile accounts (their model is to skim off 3% of sales in addition to setup and hosting fees - despite this, Demandware still has a "burn rate") that they don't exactly mention in their press releases. A SaaS (“Software as a Service”) provider such as Demandware is nowadays caught in the crossfire, under incredible pressure from three fronts: powerful and robust, open source ecommerce solutions leverage the cost argument (Magneto), Java-based solutions are starting to get long-in-the-tooth in the face of massively scalable new technologies such as Ruby-on-Rails, and developments in cloud computing leverage the hosting argument. Predictably, Demandware and their PR corps is hard at work dissembling so as to position themselves as the "worry-free package for merchants without in-house technology competence". Of course, this competence is easily found on the cheap now that it is no longer 2000, and J2EE for ecommerce seems (to many) like a complex, costly, code-bloat dinosaur. Read the commentary below and make up your own mind, Dear Reader. It will be interesting to see if they are able to hold on -- I'm rooting for them, however, if I were you and your enterprise, I would still take a long, hard look at Magento, Shopify, or other ecommerce providers. And I would have a lot of tough questions like the ones below ready for the Salespeople and PR types]

So Demandware may even IPO one day – although despite all the optimism about 2009, this year is still looking grim for new issuances. A recent report from Ernst & Young found that the pipeline of companies waiting to go public in the United States dwindled to 80 companies at the end of the second quarter, down from 90 companies three months earlier. There have been seven IPOs so far in 2009.

Demandware is a SaaS (Software as a Service) provider, and with all the controversy surrounding my incorrect, retracted tweet, I have been thinking about some of the reasons enterprises might decide against adopting a SaaS model for their ecommerce operations.

Although it can be tempting for large retail enterprises to partner with a SaaS ecommerce platform vendor to quickly launch an online store for short-term gains, it is important that the CIOs of these retail enterprises develop a defined SaaS strategy and incorporate it into their other long-term application and IT infrastructure plans. One of the most important aspects of this SaaS strategy must be an “exit strategy” for when they may want to bring the online storefront in-house. Hard to blame any company for ditching the revenue-sharing model.

It is vital that when these retail organizations evaluate SaaS ecommerce providers, they evaluate the competing ecommerce platform vendors on whether or not they have a plan and method in place to get the retail enterprise off the SaaS platform – in other words, what is the exit strategy in the long term? Five years out, when the online storefront is growing and becomes a cornerstone of the company’s total revenue stream, how does the retailer migrate the storefront back into the corporate IT environment if the management of the company decides to reintegrate? After the first two years of a SaaS deployment, many enterprises find that cost savings begin to break down. Five years from initial deployment, will it be possible to reestablish control over the online retail presence?

Choosing an ecommerce platform vendor working with hosted technologies that align with the enterprise’s internal IT infrastructure (Microsoft .Net technologies vs. Java? Oracle, MS SQL Server, or MySQL?) could potentially ease migration pain down the road and enable cost savings when and if the decision to internalize critical ecommerce operations is made.

Ecommerce “on demand” software salespeople may try and attract a large retail organization with the promise of utility pricing – it may even sound so good that the large retail enterprise may be tempted into bypassing their normal IT department’s procurement specialists. This is not a good idea. Real utility pricing is almost certainly not as flexible as initially presented and true utility pricing is rarely available. Because many SaaS contracts do not allow for volume reductions, some critics have labeled this licensing model as “shelfware as a service”.

It is critical that large retail organizations negotiate the ability to reduce users. Do not allow the “on demand” vendor to lock the enterprise into negotiations before agreement on this basic principle is reached. If the “on demand” ecommerce platform vendor does not or will not agree to this basic tenent, then refuse over-committal and negotiate escalating discounts for incremental spend in volume bands. Large retail organizations should always remember that SaaS licensing models provide steady and stable revenue streams for ecommerce “on demand” vendors and because of this, the market is becoming increasingly competitive. (Demandware’s competition includes Marketlive ecommerce, among many others) Large retail organizations have immense leverage which can be used to achieve significant licensing concessions and discounts on larger competitive deals. In addition, given the increasing and continual downward pressure on SaaS pricing, single year deals are much preferred but it is essential to secure price caps on renewals.

The vendor’s “on demand” production environment should also be scrutinized carefully. Some questions to get answered in writing may be: How often are changes made to the production environment? What is the breakdown of changes to the production environment by category? What percentage of changes had to be rolled back, or reverted? What sorts of regression tests are performed after a software patch / upgrade / code iteration?

It is vital that a keen eye is focused on the SaaS vendor’s churn and churn management (for instance, Demandware has recently lost two major accounts that you won’t read about in their press releases, including Playboy International and the Vermont Teddy Bear Company) policies. For example, how many customers have they lost in the past 6, 12, 24 months? Is their customer retention improving over time? What percentage is the customer churn compared to their customer base? What is the average duration of customer retention? What is the breakdown, broken out by reasons for customer churn? Beware of salespeople and marketing types who count “brands” as individual customers. A customer is a retail organization, not each of their individual product lines counted separately as “brands”.

Some ecommerce “on demand” vendors also provide for fulfillment services (if they do not, the retail organization will have to continue to provide these services as a normal operating business expense). High volume retail ecommerce by necessity implies that these operational expediencies are being handled with great care and efficiency. Some questions to ask: what is the status of your inventory? What box is located where? What function or customer would be affected by a loss of a certain box? When does your software / support contract expire and what might this expiration impact?

Another primary focus for corporate ecommerce vendor selection decision makers is the emergence of platform-as-a-service providers such as Amazon’s EC2, IBM and Google as well as Microsoft. Large retail organizations can use these platforms to build myriad applications, services and workflows not only to conduct online sales but also to perform advanced predictive analytics, gather fundamental mail order management metrics like future value of a customer and enable billing services to be moved into the cloud – all while providing immense capabilities for increasing uptime and availability during the high volume holiday shopping season.

Some best practice ecommerce SaaS platform selection guidelines could also include data backup and disaster recovery policies, adherence to corporate IT standards regarding accepted technologies and development tools and languages that internal software development resources and departments are familiar with. SLAs (Service Level Agreements) should be examined from ecommerce platform vendors that explore not only DR policies, but also help desk support, performance and uptime, so that buyers of SaaS ecommerce hosting services have a stronger sense of what they are purchasing.

Large retail enterprises have special needs to link internal billing and operational IT systems and external hosted ecommerce systems. Security, billing, fulfillment and compliance requirements differ from industry to industry and over-reliance on a hosted ecommerce service provider should be carefully examined. Retail enterprise decision makers may decide to get back to the fundamental vendor selection process, and take a long hard look at vendor viability in addition to the solution functionality provided by each hosted ecommerce service provider. These decisions should extend past the initial glow of cost savings in the first years of an ecommerce storefront deployment.

In a Feb 20th, 2009 research report, Forrester polled 352 corporate IT decision makers and asked them why they are not interested in SaaS:

Total Cost Concerns 37%

Security Concerns 30%

SaaS Application Mismatch to corporate reqs 25%

Integration Issues 25%

Lack of Customization 21%

Application Performance 20%

Complex Pricing Models 16%

Vendor Lock-In 14%

Other Reasons 13%

What is the difference between Cellular and PCS? May 17, 2009

Posted by hubtechinsider in Definitions, Fiber Optics, Mobile Software Applications, Telecommunications, Uncategorized, VUI Voice User Interface, Wireless Applications.
Tags: cellular, networking, pcs, Telecommunications
1 comment so far

Cellular is dual-classified as being inclusive of both analog and digital networks. Cellular networks began with analog infrastructures, and over time migrated this infrastructure to digital. In a cellular network, depending upon your location throughout the world, the operation frequencies are 800MHz to 900MHz band. Cellular infrastructure is generally based on a macrocell architecture. Macrocells involve a coverage area with a diameter of around 8 miles, and because of this large coverage area, cellular operates at high power levels, in a range of .6 to 3 watts.

PCS is a more recent technology, and has been all digital since inception. As with cellular, depending upon where you are located in the world, the frequency band of operation is in the 1.8GHz to 2GHz band. Instead of cellular macrocells, PCS uses two different infrastructures, both microcell and picocell. As these names imply, the coverage areas of these architectures are smaller than macrocells, around 1 mile in diameter. As a result, PCS uses much lower power levels – 100 milliwatts.

So the key differences between PCS and cellular are the frequencies in which they operate, coverage areas of their different cell architectures, and the power levels each uses to transmit signals. They work essentially the same way, use the same types of network elements, and perform the same functions.

The SONET and SDH Signal Hierarchy: How many T-1s are in an OC-1, OC-3, OC-12, or OC-48? May 10, 2009

Posted by hubtechinsider in Definitions, Fiber Optics, Telecommunications, Uncategorized.
Tags: Fiber Optics, networking, Telecommunications
add a comment

I have found that there exists out there in the wide world a touch of confusion when it comes to recognizing the different signal levels and transmission speeds associated with what is referred to in the telecom industry as digital hierarchies, the two most common of which are, in North America, the PDH and SDH, or SONET, hierarchies.

Throughout my work as a telecommunications enthusiast, a pastime of discovery which has kept me occupied ever since my teen years, and on through many of my professional pursuits, I have always served as a point of reference for others in regards to the various telecommunications signal levels as well as the transmission speeds that these levels in the hierarchies represent. The following is my rough attempt to put this information into one place that can serve as a reference for me and others:

SONET was developed to aggregate, or multiplex, circuit switched traffic such as T-1, (E-1 in Europe) T-3, and slower rates of data traffic from multiple sources on fiber-optic networks. SONET transports traffic at high speeds called OC (Optical Carrier). The international version of SONET is called the synchronous digital hierarchy (SDH). SDH carries traffic at synchronous transport mode speeds. Equipment interfaces make SONET and SDH speeds compatible with each other, so the same SONET switching equipment can be used for both OC and SDH speeds.

OC-1 operates at 52 Mbps and is equivalent to 28 DS-1s (same as a T-1) or 1 DS-3 (same as a T-3). OC-1 is generally used as customer access lines. Early-adopter types of customers such as universities, airports, financial institutions, large government agencies, and ISPs – use OC-1.

OC-3 operates at 155 Mbps and is equivalent to 84 DS-1s (same as a T-1) or 3 DS-3s (same as a T-3). OC-3 speeds are required by end users such as companies in the aerospace industry and high-tier ISPs.

OC-12 operates at 622 Mbps and is equivalent to 336 DS-1s (same as T-1) or 12 DS-3s. This is another capacity towards which high-tier ISPs are moving. It was originally deployed for the metropolitan area fiber rings built out across cities worldwide, although those rings are now moving to OC-48.

OC-48 operates at 2,488 Mbps and is equivalent to 1,344 DS-1s (same as a T-1) or 48 DS-3s (same as a T-3). This capacity has been deployed for backbone, or core, networks. Today the metropolitan area rings are moving from OC-48 to OC-192.

OC-192 operates at 9,953 Mbps and is equivalent to 5,376 DS-1s (same as a T-1) or 192 DS-3s (same as a T-3). OC-192 is in use for backbone networks.

OC-768 operates at 39,812 Mbps and is equivalent to 21,504 DS-1s (same as a T-1) or 768 DS-3s (same as a T-3). Use of OC-768 is very rare outside of testing or research networks due to the great expense of this transmission speed level.

At times, you may see OC levels such as OC-1c, OC-3c, OC-12c, etc. This is called concatenation, and it puts streams of data into one fat, or high-bandwidth, contiguous stream. For example, OC-1 speeds of 52 Mbps may be used to carry broadcast video. In this case, OC-1c, or concatenated OC-1, carries OC-1 streams back-to-back. These streams travel contiguously through the network as long as capacity is available. Most applications for concatenation are high-speed data and broadcast-quality video.

As far as the DS, or Digital Signal Levels, of the older PDH, or Plesiochronous Digital Hierarchy (plesiochronous means “minute variations in timing”), they follow what is known as the T-carrier signal levels. Technically, the DS-x and CEPT-x terminology (DS-1, DS-3, CEPT-1, CEPT-3, and so on) indicates a specific signal level (and thus usable bandwidth), as well as the electrical interface specification. T-x and E-x terminology (T-1, T-3, E-1, E-3, and so on) indicates the type of carrier – a specific implementation of a DS-x/CEPT-x. More often than not these days, however, the terms DS-x and T-x are used interchangeably. So some people might use the term DS-1 and T-1 to refer to the same thing – a digital transport that can carry 1.544 Mpbs over a total of 24 voice channels. In Europe, the same is true: E-1 is the same as CEPT-1, and so forth.

A DS-0 (T-0) has a bit rate of 64 Kbps and carries 1 voice-grade channel.

A DS-1 is equivalent to a T-1 and has a bit rate of 1.544 Mpbs and carries 24 voice channels.

A DS-2 has a bit rate of 6.312 Mpbs and carries 96 voice channels, equivalent to 4 T-1s. This is also sometimes referred to as a T-2, or T2.

A DS-3 has a bit rate of 44.736 Mpbs and carries 672 voice channels, equivalent to 28 T-1s. This is also sometimes referred to as a T-3, or T3.

A DS-4 has a bit rate of 274.176 Mpbs and carries 4,032 voice channels, equivalent to 168 T-1s. This is also sometimes referred to as a T-4, or T4.

Want to know more?

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m the Senior Technical Project Manager at eSpendWise, I’m a serial entrepreneur and the co-founder of Tshirtnow.net.

Measuring Voice Quality in a VoIP environment May 1, 2009

Posted by hubtechinsider in Telecommunications, Uncategorized.
Tags: networking, Telecommunications, VoIP
add a comment

One of the consequences of installing Voice over IP systems is that the “voice” sides of information technology departments are learning the lingo and technology of measuring voice quality on data networks. In addition, staffs that manage data networks are becoming aware of the criticality of voice. They are developing a cognizance of the impact on voice services of congestion when they add new applications. They also note lost voice service when they take down the network for maintenance or new installations.

Staff use network management tools that entail quality of service assesments to monitor the following factors in voice quality:

* Packet loss refers to the network dropping packets when there is congestion. Packet loss results in uneven voice quality. Voice conversations “break up” when packet loss is too high.

* Latency refers to delays when voice packets transverse the network. Latency is measured in milliseconds. It results in long pauses within conversations and clipped words.

* Jitter is uneven latency and packet loss resulting in noisy calls that contain pops and clicks or crackling sounds.

* Echo, hearing your voice repeated, is often caused when voice is translated from a circuit switched format to the IP format. This is usually corrected by special echo-canceling devices.

The true meaning of “Getting someone’s Goat” April 30, 2009

Posted by hubtechinsider in Definitions, Uncategorized.
1 comment so far

The expression, “To get someone’s goat”, meaning to anger or irritate, originated in 19th century racing stables in England. High-strung race horses were kept calm by having them share the stables with a goat. Evidently, the company calmed them and allowed them to rest and relax. Unprincipled hooligans would sometimes sneak into the stable at night and remove the goat. The horse got upset, would not have a good rest, and lose the race the next morning.

An exploration of telecom USOC (pronounced “U-Sock”) codes April 22, 2009

Posted by hubtechinsider in Uncategorized, Telecommunications, Definitions.
Tags: networking, Telecommunications, defin
2 comments

Uniform Service Order Code (pronounced “U-Sock”) is a structured language that allows for the development of software to support service order systems in the telephone industry. The service order process utilizes the USOC, along with Field Identifiers (FIDs), to provision, bill and maintain services and equipment. USOCs can be either three or five alpha/numeric characters. A plus (+) sign indicates a variable suffix position. Suffixes define options of the USOC i.e. color, jurisdiction, speed. To prevent confusion the letter “o” is used and zero is not; the number “1″ is used and the letter “I” is not. USOCs are designed for tariffed services, official company services, coin services, equipment, detariffed services, etc. The Bell operating companies in the United States and many independent telephone companies use USOCs to communicate both within their company and between companies. Many new companies in the industry are using the USOC information to interpret incumbent telephone company records when they are supplying new service to a customer. The different companies may have different names for the same services, but the USOC name is generic and therefore becomes a common naming device between companies.

Want to know more?

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m the Senior Technical Project Manager at eSpendWise, I’m a serial entrepreneur and the co-founder of Tshirtnow.net.

An explanantion of telecommunications industry CLLI “Silly” Codes April 20, 2009

Posted by hubtechinsider in Definitions, Fiber Optics, Telecommunications, Uncategorized, Wireless Applications.
Tags: networking, Telecommunications
1 comment so far

What the heck is a “Silly” Code? Allow me to explain…

A CLLI, (pronounced “Silly”) code is a telecommunications industry-standard and is an alphanumeric code of 11 characters, CLLI was developed by Bellcore (now telecordia Technologies) as a method of identifying physical locations and equipment such as buildings, central offices, poles, and antennas. Each CLLI code conforms to one of three basic formats (Network Entity, Network Support Site and Customer Site). Each format, in turn, determines how these six coding elements are used:

- Geographical Codes (Example: DNVR = Denver) Typically assigned to cities, towns, suburbs, villages, hamlets, military installations and international airports, geographical codes can also be mapped to mountains, bodies of water and satellities in fixed-earth orbit.

- Geopolitical Codes (Example: CO = Colorado) Typically assigned to countries, states and provinces, geopolitical and geographical codes can be combined to form a location identifyer that is unique worldwide.

- Network Site Codes (Example: 56 = A Central Office on Main Street) This element is used with geographical and geopolitcal codes to represent buildings, structures, enclosures or other locations at which there is a need to identify and describe one or more functional entities. This category includes central office buildings, business and commercial offices, certain microwave-radio relay buildings and earth stations, universities, hospitals, military bases and other government complexes, garages, sheds and small buildings, phone centers and controlled environmental vaults.

- Network Entity Codes (Example: DS0 = A digital switch) This element can be used with geographical, geopolitical and network-site codes to identify and describe functional categories of equipment, administrative groups or maintenance centers involved in the operations taking place at a given location.

- Network Support Site Codes (Example: P1234 = A telephone pole) This element can be used with geographical and geopolitical codes to identify and describe the location of international boundaries or crossing points, end points, fiber nodes, cable and facility junctions, manholes, poles, radio-equipment sites, repeaters and tall stations.

- Customer Site Codes (Example: 1A101 = A Customer) This element can be used with geographical and geopolitical codes to identify and describe customer locations associated with switched-service networks, centrex installations; Trunk forecasting, cable, carrier or fiber terminations, NCTE, CPE and PBX equipment, military installations, shopping malls, universities and hospitals.

Consider the real-life example of NYCMNY18DS0. The first four characters identify the place name (NYCM is New York City Manhattan). The following two characters identify the state, region, or territory (NY is New York). The remaining five chracters identify the specific item at that place (18DS0 is the AT&T 5E Digital Serving Office on West 18th Street, between Seventh and Eighth Avenues). Phone companies use CLLI Codes for a variety of purposes, including identifying and ordering private lines and trapping and tracing of annoying or threatening calls.

CLLI Code – Facility Identification codes provide unique identification of facilities (cable and carrier systems) between any two interconnected CLLI coded locations. The CLFI code is a variable length, mnemonic code with a maximum of 38 characters. Example: 101T1LSANCA03NWRKNJAA. This example says that there is a T-1 carrier connected between the Los Angeles, California Central Office to the Newark, New Jersey Central Office.

Want to know more?

About the author.

I’m Paul Seibert, Editor of Boston’s Hub Tech Insider, a Boston focused technology blog. You can connect with me on LinkedIn, follow me on Twitter, even friend me on Facebook if you’re cool. I own and am trying to sell a dual-zoned, residential & commercial Office Building in Natick, MA. I have a background in entrepreneurship, ecommerce, telecommunications and software development, I’m the Senior Technical Project Manager at eSpendWise, I’m a serial entrepreneur and the co-founder of Tshirtnow.net.

« older posts

	Product Roadmaps \| F… on What is a Product Roadmap? Wha…
	excelandaccess on What is the frequency response…
	excelandaccess on About
	Embracing Opportunis… on Five tips for recruiters on co…
	excelandaccess on Demandware gets Round D fundin…

May 2013
M	T	W	T	F	S	S
« Apr
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31

Boston Project Manager, Paul Seibert April 24, 2013

More Articles From Boston’s Hub Tech Insider:

Share:

Like this:

What are some good books on User Interface design? How do you define user interfaces in your software specification documents? The Hub Tech Insider User Interface Design Bookshelf July 31, 2011

More Articles From Boston’s Hub Tech Insider:

Share:

Like this:

What is a Product Roadmap? What is an Engineering Roadmap? July 21, 2011

What is a Product Roadmap? What is an Engineering Roadmap?

How do you create a product roadmap? How do you create an engineering roadmap?

Prioritizing product and engineering roadmap features

Using multiple roadmap documents

Showing multiple product lines on roadmap documents

Five tips for creating product roadmaps

Product roadmaps

Platform roadmaps

Vision roadmaps

Marketing roadmaps

Technology and Engineering Roadmaps

Product roadmap template

Engineering roadmap template

Related articles

More Articles From Boston’s Hub Tech Insider:

Share:

Like this:

Needham’s Sonian, a provider of email archiving solutions, raises $4 Million December 20, 2010

Related Articles

Share:

Like this:

Wilbraham MA based FloDesign Wind Turbines prototypes are 3 times more efficient than 3 bladed windmills October 30, 2009

Share:

Like this:

Waltham MA based Inverness Medical Innovation Systems acquires Seattle based Free & Clear for around $130 Million October 29, 2009

Share:

Like this:

The Twenty Laws of Testing Computer Software September 24, 2009

Share:

Like this:

Eight ways to tell if your project team is on the way up or on the way down June 21, 2009

More Articles From Boston’s Hub Tech Insider:

Share:

Like this:

Five tips for recruiters on contacting potential job candidates in a tough job market June 15, 2009

Share:

Like this:

What is “management by walking around”? June 13, 2009

Share:

Like this:

What is an ACNA? What is a CCNA code in telecommunications? June 8, 2009

More Articles From Boston’s Hub Tech Insider:

Share:

Like this:

Demandware gets Round D funding of $15MM and works to answer SaaS ecommerce challenges, under incredible marketplace pressures May 23, 2009

Share:

Like this:

What is the difference between Cellular and PCS? May 17, 2009

Share:

Like this:

The SONET and SDH Signal Hierarchy: How many T-1s are in an OC-1, OC-3, OC-12, or OC-48? May 10, 2009

More Articles From Boston’s Hub Tech Insider:

Share:

Like this:

Measuring Voice Quality in a VoIP environment May 1, 2009

Share:

Like this:

The true meaning of “Getting someone’s Goat” April 30, 2009

Share:

Like this:

An exploration of telecom USOC (pronounced “U-Sock”) codes April 22, 2009

Share:

Like this:

An explanantion of telecommunications industry CLLI “Silly” Codes April 20, 2009

More Articles From Boston’s Hub Tech Insider:

Share:

Like this:

About...

Admin Controls

Email Subscription

Subscribe to HubTechInsider (RSS)