Function Points are NOT an Estimating Model

It continually amazes me that there is such confusion in the marketplace and in industry about function points (FPA) and their role in estimating the cost or effort associated with a software development project. First and foremost, Function Points are NOT an estimation model.

(Note: for a basic primer on IFPUG Function Points, send me an email and I'd be happy to send you a copy of my article "Requirements are the Size of the Problem".)

Function points (unadjusted and the "functional size") strictly represent the size of a piece of software based on its functional requirements. The allocation of "points" to the functions performed by the software is based on assigning a standard ordinal number to a "function" that the software must perform (a unit of work). Currently, the most popular methods of function point sizing based on the International Software Benchmarking Standards Group (ISBSG) productivity database are the International Function Point Users Group (IFPUG) method, and the Finnish Software Measurement Association (FiSMA) function point method.

The function point (or functional) size is similar to the square foot size of a building's floor plan (or square m) - it is one measure of size - and it works well as part of determining many things.
BUT size is not the same thing as estimation OR AN ESTIMATING TECHNIQUE!

Function point size can be used (along with MANY other factors) to determine work effort to develop (build) the software. Productivity factors or delivery rates (FP/hour) are derived by taking the FP size of a piece of software, together with the work effort hours it took for a team to build it (based specifically on the TYPE of software, the requirements for QUALITY (reliability, accuracy, functionality, usability, etc), the skills, and WHAT TASKS WERE INCLUDED!

Here's the crux: FUNCTION POINTS DO NOT EQUAL WORK EFFORT HOURS OR COST. While size is a major driver (in the same way that a larger house takes more time to build), the relationship between FP and effort or cost is NON-LINEAR! There are many more factors that just raw size involved in determining the cost and effort to build software.

It may be helpful to consider an analogy (again one based on construction - which is not a perfect analogy but one that serves to illustrate). If I need a 1000 square foot building - can you tell me how long it will take to build? And what can I anticipate will be the cost of that building? The answer is that it depends on MANY factors (such as location, pre-existing structures, type of building: anufactured, or custom or prefabricated or whatever), and many other things. Builders might provide me with an average delivery rate based on STANDARD characteristics (like a standard home with 2 bedrooms and a living room, kitchen and bathroom in the US midwest), and an average effort based on what similar buildings have taken to build IN THE PAST HISTORY. However, there is not ONE rate for all structures - it varies based on location, type of construction, building codes, labor costs, etc.)

The same is true when we consider function point size and the effort and cost it will take to build a piece of software. Consider the aforementioned example applied to software development: How much cost and how much effort will it take to build software that is 1000 FP? The appropriate answer is that it depends on the characteristics of the software, labor costs, methods of construction, AND its functional size. The software measurement and development industry has developed rates of FP / hour and cost per FP for projects with "standard" and similar characteristics (recall the "average" price per square foot or average rate to build?) Note that any "average" rate is BASED ON PAST PROJECTS (that took "x" amount of hours to build a particular size, type, and similarly constrained by quality, system - but there is not a one size fits all rate!

New Book available to explain these and other concepts about Function Point sizing: I am proud of the new book I co-authored with Manfred Bundschuh (formerly the measurement coordinator for AXA Insurance in Germany). It was published in Sept 2008: The IT Measurement Compendium - Estimating and Benchmarking Success with Functional Size Measurement (the Amazon link is featured together with reviews by Capers Jones, and also by Peter Hill (Executive Officer for ISBSG at http://www.qualityplustech.com/books.html).

The book outlines and explains in clear English these concepts and presents all five of the ISO/IEC conformant Functional Size Measurement Methods including the aforementioned two: IFPUG and FiSMA, as well as NESMA from the Netherlands, Mark II from Britain, and COSMIC by the COSMIC consortium.

Have a great week, and please let me know what you think of this and other postings here.

p.s., To all of you who attended my webinar on December 3, 2008 "The Certified Scope Manager (CSM) - A New IT Job Role) sponsored by CAI - thank you! If you missed it, send me an email and I'll put you in touch with the site that has options to listen to the recording.

Best regards,
Carol

Carol Dekkers email: dekkers@qualityplustech.com http://www.qualityplustech.com/ http://www.caroldekkers.com/

Contact Carol for your keynote and speaking needs - she translates technical subjects into easily digestible soundbites - in a humorous and forthright manner. See http://www.caroldekkers.com/ for details of topics and opportunities.

View also Carol Dekkers' general blog at http://caroldekkers.wordpress.com/

============Copyright 2008, Carol Dekkers ALL RIGHTS RESERVED =============

Certified Scope Manager - the new IT Job Role - FREE webinar this Wed. Dec. 3, 2008

The Professional Certified Scope Manager (CSM) - a New IT Job Role. – A webinar presented by Carol Dekkers
December 3rd, 2008-- 11:00 am - 12:30 pm Eastern Time

To register (there is no charge to attend this webinar), visit: http://solutions.compaid.com/forms/WebinarA20081203?ProcessType=PreReg

Are you worried about your job when we're all expected to do the same as yesterday but achieve better results? All this while we have tightened budgets, less time to complete our work, and little time for rework or risk-laden technology investments. Learn from Carol Dekkers, a main partner in the European Certificates Association for the Certified Scope Manager (CSM) job role, how becoming a Certified Scope Manager could insulate you from a potential job cut.
Recessions bring many things including added stress and discomfort for customers needing to streamline their business with uncertain technology solutions. Fixed price budgets do not serve either suppliers or customers well without solid requirements and in a down-turned economy, timeframes and resources are tightened even further.

The impact of rework, missed deadlines, budget excesses, and projects with missing or incorrect requirements is difficult to gauge, but blame increasingly is found to be shared equally between the customer and supplier. As a result of the ongoing frustration and the lack of an objective third party similar to a real estate agent, software intensive systems development may continue to derail until such time as accountants step in with their own cost-based accounting and other manufacturing approaches to remedy what they see as the issues.

This doesn’t need to happen. In the same way as a homebuyer hires a real estate agent to assist them in their search, evaluation, inspection, acquisition, financing (mortgage), and closure of a property to meet their needs (which may include construction and renovation); a new IT job role – that of a Certified Scope Manager (CSM) – can serve an analogous role on IT projects. Scope management is an emerging concept whereby a "scope manager" works throughout the preliminary requirements through to final delivery with software acquirers and suppliers to alleviate the scope management related ills that plague software intensive systems.

In this webinar, join 4SUM Partner, and Quality Plus Technologies President, Carol Dekkers and find out what is involved in the emerging job role of a Certified Scope Manager as defined by the European Certificates Association and the northernSCOPE™ concept from Finland. Ms. Dekkers is the author of two 2008 books related to scope management: Program Management Toolkit for software and systems development (published by Talentum) and The IT Measurement Compendium: Estimating and benchmarking success with Functional Size Measurement (published by Springer). Carol is heavily involved as a main partner in the European Certificates association for the Certified Scope Manager (CSM) job role, and she frequently gives keynote presentations on software measurement, scope management, global software development, and project management at international software conferences.

Target audience: Anyone who has a role in the success of a software or systems project including project managers, systems analysts, business analysts, quality assurance specialists, software and systems acquirers, metrics specialists, steering committee members, project sponsors, prospective scope managers, etc.

Learning takeaways from this webinar:
· Learn why scope management alleviates six of the top ten reasons for project failure
· Understand the 12 steps necessary for success with the northernSCOPE™ concept
· Discover if your skills match up with the mandatory pre-requisite and acquirable job requirements to become a CSM
· Identify the critical success factors for a CSM to make a clear difference on software intensive systems projects anywhere in the world.

To register (there is no charge to attend this webinar), visit: http://solutions.compaid.com/forms/WebinarA20081203?ProcessType=PreReg

Have a good week!
Carol
Carol Dekkers
email: dekkers@qualityplustech.com
http://www.qualityplustech.com/
http://www.caroldekkers.com/

Contact Carol for your keynote and speaking needs - she translates technical subjects into easily digestible soundbites - in a humorous and forthright manner. See http://www.caroldekkers.com/ for details of topics and opportunities.

View also Carol Dekkers' general blog at http://caroldekkers.wordpress.com/

============Copyright 2008, Carol Dekkers ALL RIGHTS RESERVED =============

Certified Scope Managers (CSM) Alleviate Customer Stress on Software Projects

-- Read to the end of this post for a free webinar offer Dec. 3, 2008 --

Can you imagine purchasing or building a new residence today without having the internet and real estate resources to assist with pricing comparisons, market research, neighborhood planning and demographics (including crime statistics, trends, etc.), arranging for an inspection, title transfer, mortgage financing, bids and closing, etc.? This is exactly the situation on many software development projects - the customer knows that they need a technology solution to business problems but often must navigate through the software development process on their own - with only the builder (software developer) to guide them through. Until now, that is! Introducing a new professional job role that we are standardizing in Europe through the European Certificates Association - the Certified Scope Manager (CSM).

In building construction/home buying, a buyer who works without the support of third parties to assist (real estate agents, general contractor, architects, etc) in negotiations and ongoing communication with the seller or builder, would be stressed out. The sheer number of activities and issues in the processes can be overwhelming, and an independent buyer becomes highly dependent on the honesty and trust relationship they personally establish with the seller or builder. In addition, buyers without a background in home sales or construction often enter the process rather innocently and find that the overall purchase or construction can be one of the most stressful events possible. Not only is a residence the largest single capital investment most people ever make, its acquisition is laden with emotion and a number of expectations of what the residents will experience (hopefully happy and stressfree) once the move is complete.

In software development there's different players involved and also a far bigger investment at stake, yet many customers have relied for years on "fixed price" contracts that begin before requirements (when no one knows exactly what is required!) Suppliers in such instances typically "pad their estimates" to cover any eventuality because of the vagueness of the requirements in the RFP. No wonder the overall projects end up overbudget and behind schedule! What we need in software development is a real estate agent for acquirers -- and the good news is that in Finland and Australia, it's already a reality in the form of a Scope Manager!

Free webinar: JOIN ME ON DEC. 3, 2008 from 11:00 am to 12:30 pm EST for a free webinar: The Professional Certified Scope Manager (CSM): A new IT Job Role. – A webinar presented by Carol Dekkers

To register (there is no charge to attend this webinar), visit: http://solutions.compaid.com/forms/WebinarA20081203?ProcessType=PreReg

I look forward to welcoming you there!

Have a great week,
Carol

Carol Dekkers
email: dekkers@qualityplustech.com

http://www.qualityplustech.com/
http://www.caroldekkers.com/

Contact Carol for your keynote and speaking needs - she translates technical subjects into easily digestible soundbites - in a humorous and forthright manner. See http://www.caroldekkers.com/ for details of topics and opportunities.

View also Carol Dekkers' general blog at http://caroldekkers.wordpress.com/ ============Copyright 2008, Carol Dekkers ALL RIGHTS RESERVED =============

GSD (Global Software Development) = Challenges Times X

(Photo of Global Software Development workshop participants from 9 countries at EuroSPI2 2008, Dublin Ireland, Sept 2008)

Global software development is the new normal as offshoring, outsourcing, insourcing, farmsourcing, and other forms of software development are no longer a novelty. The variations on the theme are almost endless as the BRIC countries (Brazil, Russia, India, and China) are also in turn finding their own sources of cheap labor in Africa and other developing societies. Latvia, Romania, Slovakia, Estonia and other Baltic countries are often the preferred outsourcing partner for software acquirers in Europe due to their geographic proximity, lower cost of labor, highly qualified workforce, and time zone accessibility. While unusual for North Americans to fret about time zone differences with India - more often the difference is seen as a plus ("we leave them with a problem at the end of our day and it is solved when we arrive to work in the morning") - Germany and other European nations prefer to outsource software development to Baltic countries because of the four hour time difference they'd experience with India.

Multicultural teams are becoming more common even within our own country as corporations such as Nielsen (aka the Nielsen ratings people) and others hire Indian workers to temporarily relocate to the US to gain the experience before taking the work back offshore to complete in India. As such, the US and Canada are becoming more and more the "melting pots" of folklore fame.

What does all of this mean to professionals unaccustomed to dealing with a variety of cultures in our workspace? The issues are more than a simple fact of ethnicity and differences in geography, and our diversities may surprise you. Diversity in the workplace now spans the following major areas:

- Age - Never before has our workforce featured workers from four generations: Baby boomers, Generation X, Y AND Z. The differences in generational background, values, expectations and entitlement can be vast and without consideration can cause major friction on project teams. This includes viewpoints on taboo subjects such as abortion, gender rights and differences, domestic relationships, career expectations and loyalties, and commitment to working hours.

- Gender - North America and Europe (to a lesser extent) has covered gender relations over the past decade with authenticity and focus through sexual harrassment training and diversity workshops. However, this is not the case for all nationalities where gender treatment may be tied to national or religious cultures. There are nationalities who immigrate to the US for work who refuse to acknowledge or shake hands with a woman in the workplace - this can cause friction on teams - especially when co-located.

- Ethnicity - This is the one most people think of when considering organizational or multicultural work environments. The most common areas to be conscious of and cognizant of differences lies in the "innocent" areas of food and festivals. For further information refer to the seminal works of Geert Hofstede or Fons Trompenaar on multiculturalism.

- Multidisciplinary - Various disciplines involved on project teams can cause more difficulties in terminology than even language. Medical practitioners and software developers (for example) seldom speak the same language yet many of their "TLA's" (Three Letter Acronyms) may be identical with completely different meanings. An example is AMA which can mean American Medical Association, Alberta Motor Association, and American Management Association. Real life examples on projects is much more pervasive and can cause friction when the acronym meanings are taken for granted.

- First language - in my other blog (http://www.caroldekkers.wordpress.com/) I've mentioned how fortunate we in Canada (English Canada that is) and in the USA are to speak English as our first language, especially since it is the international language of business. When working with others whose first language is not English, idioms, dialects, local language usage (British versus Australian versus American versus Canadian forms of English can be VERY different) can cause problems if not dealt with in a considerate manner. For example, even when dealing in English, the term "to table a document" means almost complete opposite ideas in British English versus American English (in the US we mean to put a document aside, whereas in Britain, the term refers to bringing up a document for immediate discussion).

- Taboo subjects - while this item is often related to ethnicity, it is not necessarily so! For example, in the book "American Backlash", the largest diversity in the United States exists between those who vote and those who do not - not the differences between genders, race, or age! Sensitivity to what will offend a particular group for whatever reason is important to consider when dealing with "multi-cultural" teams regardless of the definition of "CULTURE".

- Ability to embrace change - again, this may fall along the lines of ethnicity in some cultures, however, the willingness or ability to adapt to or embrace change is much more complicated than simply geographic birthplace. Myers-Briggs assessments, DISC and other personality evaluation models can often shed light into the types of people and their "culture" on project teams.

- Race / color /creed and associated/potential bias - this is often less related to ethnicity than to upbringing. It is interesting to me to read books by a diverse set of authors who uncover various biases in our global societies. It becomes obvious that every nation on earth has an unpublished hierarchy of ethnic respect - in other words, every nation looks at people of other nations in a different way. Americans are lauded in some societies while in others we are thought of as inferior. A colleague from Switzerland working in a middle eastern country cites the hierarchy of preferred consultants as being: United Arab Emirates, Australians, British, Americans, European Union countries, then others. Other countries have their own preferences and biases - and even a short trip to the bookstore or to another country reveals these differences in outlook quickly.

SO- global software development teams are plagued not only with the traditional customer versus developer/supplier crevasses, but also with challenges X many based on the dimensions above.

I hope this provides you with food for thought - in whatever manner you prefer your food! Happy weekend!

Carol Dekkers
dekkers@qualityplustech.com
http://www.qualityplustech.com/
http://www.caroldekkers.com/

Contact Carol for your keynote and speaking needs - she translates technical subjects into easily digestible soundbites - in a humorous and forthright manner. See http://www.caroldekkers.com/ for details of topics and opportunities.

View also Carol Dekkers' general blog at http://caroldekkers.wordpress.com/
============Copyright 2008, Carol Dekkers ALL RIGHTS RESERVED =============

Ringling School of Design Summit 2008 - Observations from a non-designer

It was a refreshing change of pace to attend an evening session and reception at the Ringling College of Art and Design’s Sarasota International Design Summit, Oct. 27-29, 2008 just a short drive south in Sarasota, Florida (http://www.sarasotadesignsummit.com/). The evening session consisted of four presenters spread over two sessions and provided insights into the world of Google, Microsoft, Adobe and Roundarch. Being more of a design focused than an engineering focused summit, I was open to receive new ideas about topics related to user "experience" that tied in with some of my thoughts about culture and globalization. It was a rarity to be at a conference where I didn't know anyone and where I was not presenting, and I was able to simply listen, observe, and digest the presentations. I'd like to share with you my highlights of the evening:

1. There is a distinct difference between web designers, students, and software engineers, and even in subdued lighting of the ballroom I sensed it. On average with the designers and students, the dress was more casual (more untucked shirts paired with jeans) than I've seen at most software engineering conferences. The gender split was also noticeable - with the designers and students, there was a 50/50 split, while most software engineering conferences are male dominated (at least 70/30 or more). Not surprisingly, the sessions at this conference were targeted on software development with a focus on enhancing the user "experience". I've never been to a traditional SD conference where I've ever heard that emulating "second life" features on a website was seen as anything but gold-plating in software development, yet at the Design Summit, it was touted as a great way of enhancing the user experience.

2. There was no difference between the Design Summit ppt files and those in traditional software engineering or academic presentations I've seen. I was surprised that the colors and asthetics of slides were of similar quality to those I've become accustomed to seeing at any technology conference - I'm not sure why I expected the layout or color schemes to be superior here, but I did. In other words, the word density per slide, the propensity of too-small-fonts, and lack of color contrast was no different that at university and highly technical presentations the world over. It was as Edward Tufte purports, powerpoint has become a crutch in too many of our presentations, and we simply fail to realize the distraction caused by busy and unreadable slides.

3. All four speakers in the evening program were male (and under 40). While it may have been pure coincidence and timing that all presenters were male, unfortunately in the software industry as a whole, there is commonly a gender imbalance with the speaker lineup. I am often surprised to see the speaker lineup mismatched to the audience breakdown. Maybe I am cynical, but I just don't buy the response given by conference organizers that "there are just so few female presenters in the field". This should be unacceptable to attendees, especially if the overall quality of the "scheduled" presenters leaves something to be desired. Let me be honest here, the Design Summit presenters WERE very good, and there were female speakers on the overall conference agenda. In terms of age, as I grow older, I realize that this is the first time in history that we have four generations in our workforce we have today (Boomers, Gen X, Gen Y, and Gen Z). I just noticed how much younger the featured evening presenters were at the Design Summit than at many other venues where keynoting experts typically are over 50.

I have more observations about the content of the presentations and particularly about how Google tackles design and how global the www world has become. I'll post these in the next couple of days. Meanwhile, in summary, what did I learn from attending this special evening event at the Design Summit? It reinforced my belief that software developers need to spend more time reading and learning from outside the their field. In other words, read the industry journals that our customers read, and explore new fields instead of simply reading Information Week or Computer World. I know for me, when I venture outside the traditional world of software development and project management, I always discover new things that propel my ideas forward and beyond into new directions than what I first thought.

Have a good week!
Carol

Offshoring Onshore - 9 Critical Lessons for Multi-Cultural Contracting

Recently, I had the unusual (for my company at least) experience of working for an India-based, US domiciled corporation on a short term contract. It was a great learning experience in many ways, and I'd recommend that the following lessons learned are critical to success when working with cultural differences:

1. Get everything (everything!) in writing -especially verbal promises - before the contract starts;
2. Be prepared to reduce your fees (negotiate down) as a part of doing business (some cultures are not satisfied unless they feel they are getting everything at a bargain price);
3. Keep track of all names and their role - and ask for correct spelling of all names, their position, their company (multiple connected companies with strict legal dividing lines is common), their role on the contract, work and mobile phone numbers and their personal (individual rather than collective) email address;
4. Realize that a single gender team is typical (you may work with an all male group by design) depending on the culture;
5. Don't ignore your intuition - it is culturally independent (usually) and is your best ally;
6. Know that gender and ethnicity biases do and will occur - just be aware and watch for these on both sides. Be slow to react to anything that might appear strange to you at first glance. Silence is golden in many cultures (as opposed to we, North Americans, who need to fill silence gaps with words);
7. Not everyone will be as receptive as you to a diversity of team members - even here in the "melting pot" of the USA.
8. General rules of US business are not necessarily followed by foreign-run companies domiciled in the US;
9. Obtain an advance for expenses and other fixed costs (or you may wait 45 days or more for reimbursement of your sunk expense costs).

Lesson #1. I was retained as a subcontractor to perform measurement consulting for an India-based company associated with a large US-based prime contractor. Because I had completed successful engagements previously for the US corporation, I neglected to perform due diligence with the new company. This led to lesson #1 above - "always get everything in writing!"

The client for the India-based organization SYSSYS wanted to set up a sustainable software measurement program that would meet the needs of their CIO and use six sigma to do so. The assignment was allocated a total of 10 onsite person days of consulting to start.

Lesson #2. The first cultural difference happened right away when the SYSSYS contracting officer insisted that the client would need a fee reduction to my billable rates. While this also happens in the US when a volume of work is involved or the consulting budget is really tight, I now know from research and colleagues that it is part of the Indian way of doing business. The line "this is an outstanding opportunity for future business" was a standard one issued verbally to imply a volume of work to come. Lesson #2 - "Be prepared to reduce your price."

Lesson #3 and Lesson #4. The next culture shock came once the work commenced. Meeting after meeting (all by conference call) was held before I ever saw a contract (a full billable day was spent) - all involving more foreign names from multiple companies who would be involved in this two week onsite project. I was the lone North American and the only female out of approximately 10 persons who got involved including subcontract administrators, managers, my Indian teammate (from CA), the onsite consultant, and various others who I never learned their role. Here it was a US based client for a US consulting project and I was the sole North American. My instincts told me that the US based client in the upper Northeast might not know (or care?) about this imbalance. I wrote down most of the names and email addresses, but it was not easy to follow who was always involved in the phone meetings. Lesson #3 - "Keep track of all names and numbers," and Lesson #4 - "All male teams are not uncommon".

Lesson #5. When we first met with the client (by conference call) in advance of the onsite work, the client team manager laid out a set of expectations for the work. My intuition kicked in full gear as I realized that the timeline and 10 days of onsite work was far too ambitious to succeed. I overrode my instincts based on assurances from the contracting organization that my fears were unfounded. My Indian colleague (a six sigma black belt) would set the scene and do the first two days of onsite six-sigma training, and then leave me to complete the work and deliver the results. Again, I supressed my intuition that told me this was a risky project with lots of potential for miscommunication. I still had no written contract - just a verbal commitment to pay me for 8 billable days plus expenses in an expedited manner, and I booked and paid for my flights to the client site on verbal assurances and the reputation of the US parent company. Lesson #5 - "Listen to your intuition."

Lesson #6 and Lesson #7. The two days of onsite training were stuffed full of content and case studies, but syncopated by frequent attendee questions of "what did he say?" whenever the Indian pronunciation of a word left listeners with puzzled looks. The client frustration with the culture, language barrier, and communication escalated and by the end of the third day, the contract was abruptly terminated. While this is rare, it does happen whenever the client expectations are unrealistic or if there is a mismatch of understanding and needs. Off the record, one of the client managers confessed that the language issue, the mismatch of the case studies to their needs, and the lack of more North Americans on the contract were contributors to the termination. Lesson #6 - "Gender and cultural biases can and do occur" and #7 - "Not everyone will appreciate foreigners".

Lesson #8. At this point, I had just received and signed the subcontract agreement (after the work commenced) and it had issues that I had not foreseen: the committed 8 billable days had been changed to client approved and signed off days. By this time it was too late to change the contract. I sent in the first invoice immediately to recover the sunk expenses and work done to date, but was told by one of the SYSSYS managers that the client would not be invoiced - implying that I might not be paid. Lesson #8 - "Rules of business in the US are not necessarily endorsed by foreign companies domiciled in the US."

More Lesson #1. Thirty days following my invoice, another company official called to tell me that I needed to complete forms to claim both expenses and fees for work performed and that they needed to be approved before I could submit the invoice that was now 30 days old. Lesson #1 - "Get EVERYTHING in writing before the contract starts".

Lesson #9. Since the onsite visit in August, I've submitted five invoices and a set of forms (previous copies all got "lost" in email in-baskets) - and it is over 75 days since the work was done. A glimmer of hope came this week when the subcontract manager emailed me asking for my mailing address (it is on every invoice) so they could MAIL OUT the checks. Lesson #9 - "Get an advance to cover expenses".

Conclusion. I love to experience different cultures and have spoken in 25 countries (including India), but a few precautions must be taken to protect oneself when contracting with other cultures. I hope these lessons learned can save you some headaches and allow you to enjoy the diversity of working and learning from other cultures here in the USA.

Have a good week.
Carol
http://www.caroldekkers.com/
http://www.qualityplustech.com/
-----------COPYRIGHT 2008 CAROL DEKKERS ALL RIGHTS RESERVED-------------------

The Future of Technology Conferences...

Depending on your age, you may or may not remember when... technology-centric conferences were in their infancy in the late 1970's. It was a time of abundance and technology was new and exciting - and colleagues would sometimes select the conference for the half-year (two to four conferences a year was the norm) - based on the exotic locale?
Without reference to age, some of us even may remember when... conferences grew larger by the hundreds every year based on positive word of mouth and the location?
Remember when... budget and training dollars were granted when you applied to go to a particular conference, and then additional dollars were authorized when you found another equally "not to be missed" conference after you got back from the first?

Those were the boomtown eighties all right! Ok, I'm old enough to recall attending international specialty workshops, training seminars, and software development conferences with hardly more justification than the conference brochure - and we certainly didn't need to submit triplicate copies for every lunch and coffee receipts for every day of every trip. Today, things are vastly different and the whole traditional, in-person conference is a big make it or break it expenditure for the corporations and not-for-profit groups alike. And, with the downward trend in attendance, it can take a single poorly attended conference to wipe-out an organization's assets. What are the challenges that technical conferences are up against these days? Here's a few of the emerging trends:

1. Increased competition for conference dollars

It is virtually impossible to keep up with the explosion of specialty "international" conferences that pop up almost weekly. It appears that anyone who sees that a buck can be made if you can just "tap the right market at the right time" seems to have gone into the conference business. ABCD (or some other clever 4 letter acronym) springs up and touts itself as "the provider of the premiere conference experience". Or it is common to read "Ixxxx Institute presents the first ever blahblahblah conference" as a conference headline. Be careful how you allocate your conference dollars before you trust the printed brochure to make sure that value will be delivered. It is good practice (but not a common practice) to call the organizers ahead of time and ask for the names of five of last year's attendees, then follow-up with them by phone or email to ask what they thought of their conference experience. Be wary if all of the attendees are board members or a member of the conference planning team. Otherwise, if the advice is "skip this one" - you know that you've probably saved your company travel money, conference fees, and workshop fees - and have crossed one tenuous conference off the list.

2. Conferences that sound too good to be true probably are.

Watch for fly-by-nights in today's money hungry economy, there are those who think that any popular topic will pack a conference - and that is partially true. Agile, SOA, Open source and Web2.0 conferences are popular and currently still amassing good turnouts. When we're talking about the amount of money generated at a well-attended conference (1000 attendees at $1000 per attendee is big bucks!), there are those who may get greedy and put customer satisfaction and value and speaker treatment on the bottom of their list of priorities. Make sure that all of the speakers listed for the conference will be appearing live and in person if you want to meet the speaker as there are conferences today that "beam in" a satellite feed of the speaker at another venue (like on the academy awards with entertainers who couldn't make the live show!) or sometimes even run a pre-recording of the speaker delivering his/her presentation. Especially watch this at conferences where the speaker lineup appears just too plentiful and illustrious to be true - because it probably is!

3. Webinars and podcasts are the rage today

Remote, small bite sized presentations on a particular (usually highly focused) topic packaged as a low-cost or free webinar seem to increase weekly. While webinars were once limited to high-technology companies seeking to demonstrate their software remotely, the webinar and podcast (usually audio only as opposed to video for webinars) frequency have taken over the mainstream of technology offering topics ranging from coding tips to software development methodology. Why go to a conference if a webinar will deliver the information directly to your desktop?

4. Open universities

Did you know that anyone with an internet connection worldwide can attend classes remotely at MIT and other major universities throughout the world? While a degree is granted only to those paying students, others can watch and learn for no cost by simply accessing the university site and selecting the topic and date for the class and "tuning in" (double clicking on the selected video link). For example, Thomas Friedman's lecture on his book The World is Flat from May 2005 at MIT can be readily viewed at anytime day or night. Visit MIT open university at http://mitworld.mit.edu/.

What's the future for technology conferences? If there's the right combination of location, people, topics, and proven good speakers delivering content rich presentations, then there will always be a market for well attended in-person conferences. However, miss one of the ingredients or have a stale or old school style conference where the same old presenters present the same old stuff at a conference run by the same old not-for-profit board members, and you're going to see a decline in attendance no matter where you locate the conference.

It's going to be interesting to see which conferences survive and thrive in 2009, and what conferences simply disappear from the landscape... any guesses from your vantage point?

Have a nice week!

Carol Dekkers
http://www.caroldekkers.com/
http://www.qualityplustech.com/
-----------COPYRIGHT 2008 Carol Dekkers ALL RIGHTS RESERVED------------------------

What we have is a Failure to Communicate

I don't know if you 've been following the technology trends of the past year or so, but a few disparate headlines keep surfacing and are not easily dismissed:

• The Percentage of Females entering Computer Science and Engineering Falls to an All Time Low (mainstream newspapers)
• Is there a link between Asperger's Syndrome and Social Skills in IT (SEPG conference presentation)
• Communication is the Bigger Part of Project Management (frequent presentations on soft skills at PM conferences)
• Innovation and Communication are two of the Areas not easily Outsourced (citing Thomas Friedman's book "The World is Flat")
• Barely 1/3 of IT Projects are Successful (Annual CHAOS reports by the Standish group)

Taken individually these topics seem harmless enough, but as I speak internationally on the topics of IT measurement, global software development (and the accompanying cultural issues), and the future of project management and quality in IT, I am struck by the common chord that permeates all of these headlines: we in computer science and engineering are stereotypically lacking in social and communication skills.

I can hear it now, anyone who's been in software and systems development for more than six months is saying, "No ****! Say something we don't already know!" I know from personal experience that few students enter engineering or computer science to gain people skills!

Recent research illuminates that computer science related professions - and in particular IT development - are so devoid of gratitude and basic human appreciation that women in particular find the environment uninhabitable over the long term. Gosh, it sounds like Mars - and in many ways, in many organizations, an IT career in software development is often like life on Mars may turn out to be. I do realize that there ARE places that are on the top 100 list of companies to work for in IT - and I applaud those companies who nurture their employees, take a solid interest in making sure that their technical experts don't burn out, have ample opportunities, and a lifelong career. But, this is not the norm - at least not amongst the worldwide cadre of corporations represented at software and systems engineering conferences at which I speak. When I routinely ask "How quickly do you find out when you've done something wrong at work?" the answer is solidly quantified by minutes. However, when I ask the same question about doing the right things or going the extra mile - the answer is met with puzzled reactions that range from "NEVER!" to "if we're lucky, maybe after a few months".

What's wrong with this picture???? We're the same human beings that interface with parents and kids at soccer games, go out socially with friends, run governments, manage companies, you name it - the professionals involved in IT have the same lives as non-IT'ers - the need for friends, socialization, families, contact, movies, money, you name it - yet when we cross the threshold of our offices, it all goes out the window. (Yes, there ARE other professions that do this as well, but I'm talking about IT right now...)

One presentation of note at an SEPG (software engineering process group) conference of the Software Engineering Institute (SEI) in the US a few years back, conjectured that perhaps the dysfunctional communication and appreciation in the IT field could be attributed to "Asperger's Syndrome" a form of early onset autism (for which the syndrome and accompanying diagnosis was not identified until 1972) - in which its sufferers lack the emotional empathy for others. In the presentation, the speakers were careful to caution audience members from labeling their co-workers who lack social skills as being autistic. But, it raised an interesting point - the room was filled to capacity and everyone seemed to be taking notes that they mentally could attribute co-workers to. I've never attended any other conference where professionals were eager to pin a lack of social skills of co-workers so readily on a medical condition. (A sidenote of interest was the research that showed a marked increase in the occurrence of early onset autism in Silicon Valley families where both parents worked in IT ).

Putting the SEPG presentation aside, still leaves the fact that soft skills are typically learned by osmosis or treated as "fluff" in IT (and engineering) despite the huge cost to our industry. During my engineering education, it was commonplace for colleagues to question why anyone would befriend non-engineers or attend non-engineering functions (which I did as a matter of course) - thinking that everyone else was either inferior (as if everyone in the world aspired to be an engineer!) or boring. Computer science wasn't much better and the cirriculums were often devoid of communication courses. Yet, in IT those very skills are the most needed and missing. Software development is a human endeavor for the most part.

What can we do about changing our world? Say a kind word, thank someone who goes the extra mile - and make it a conscious effort until it becomes a habit. As Clint Eastwood said "What we have here is a failure to communicate."

I am of the firm belief that if we put people first and technology second in our IT initiatives, and we concentrate on truly listening and learning about each other from a human perspective, our IT programs will succeed more often. And isn't process improvement and success what we need more of today - AND appreciation of the same?

Happy weekend!

Carol

http://www.caroldekkers.com/

http://www.qualityplustech.com/

-----------COPYRIGHT 2008 Carol Dekkers ALL RIGHTS RESERVED------------------------

The IT Measurement Compendium: Estimating and Benchmarking Success with Functional Size Measurement (Function Points)

It is finally available in the United States and throughout the world! Co-authored with Manfred Bundschuh, who retired as the measurement coordinator for AXA Insurance in Germany, and myself, The IT Measurement Compendium: Estimating and Benchmarking Success with Functional Size Measurement is available for order from Springer (the publisher) directly, or from Amazon.com (direct link from www.qualityplustech.com/books.html - where you can also view Capers Jones' review!)

Culminating a yearlong writing and editing endeavor, this is the first book ever to examine all five ISO conformant Functional Size Measurement (Function Points) standards AND feature a single case study that uses all five methods to derive the software size.
While function point analysis (FPA) was first invented and presented in 1979, use of the methodology became especially relevant for comparing the productivity and quality of outsourcing contracts. In addition, corporations who strive to reach level two or higher on process maturity scales such as the CMMI(TM) or the SPICE models, have discovered that functional size measurement provides an objective means of sizing software requirements - and fits into parametrics software estimating methods (as the size of the software to be developed).
For further details or for quantity discounts, please contact me directly by sending me an email at dekkers@qualityplustech.com.
Respectfully,
Carol Dekkers

-----------COPYRIGHT 2008 Carol Dekkers ALL RIGHTS RESERVED------------------------

The Economy and Software Measurement...

Every day I ponder just what power we, as individual homeowners and workers, can do about the mess our economy is in. As the owner of a small business who is reliant on having a steady stream of consulting and speaking clients, business is predictably UNpredictable. Entrepreneurs (like me) get used to the ups and downs of the business and its idiosyncracies and the dysfunctional behavior of corporate leaders.

For example, when the economy is good and business is up, companies will invest heavily in training and process improvement efforts. Yet, when the economy lags or economic growth slows, these same corporations cut out training as an excess "expense", and drop the non-mandatory (so called optional) programs such as process improvement! This is the opposite of what we do in personal life: when our income drops or the future looks less than positive, we typically start to look for a second job, cut back on non-essential spending, and go back to school for retraining. We certainly don't stop looking for ways to eliminate waste, find ways to improve, or to do things more effectively - we know that to survive we need to do just the opposite!

Yet business acts uncharacteristically to our personal lives, and does so over and over - each time anticipating different results. (Einstein called this "insanity" -- doing the same thing over and over and expecting different results!) Software measurement - the process of gauging and reporting just how well your IT department is performing in order to determine how much better we can do (through process improvement opportunities) - is perceived as "unnecessary overhead" and "not real work". Yet it is this very evaluation and measurement process that will uncover wasteful processes thereby saving the corporation time and money in the long run. Doesn't it seem like a downturned economy is the perfect time to determine where there is waste and rework hidden in your systems and software process?

I ask you this, what is a better time than today to figure out how to do things better? When our companies are losing money and squeezing workers ever harder to perform better, wouldn't that be the ideal time to figure out what NOT to do? It seems logical that major corporations need this information even more urgently in today's downturned economy. Companies NEED to know how to leverage those processes they do well on -- across the corporation, and cease doing (or change how they perform) those processes that result in underperformance and rework.

Everyone is talking about how the bleak outlook on our economy harkens back to the Great Depression, yet a few realists are actually talking about "opportunities" - acan you imagine? The optimists with an outlook toward positive change and opportunities are going to survive and thrive in this new "economy" and will lead the way in showing the remaining majority how business should be done!

Could it be that this is the perfect time to do things right - and focus on getting our corporate houses in order through measurement and comparison of methods? I believe that there has been no more POSITIVE time than now to invest wisely in software measurement rather than spending money the same way we have always done. There is a saying "If you always do what you've always done, you'll always get what you've always gotten." Isn't today the first day of an improved corporate life?.

Call me (727) 393-6048 office or email me dekkers@qualityplustech.com if you'd like to talk further about how we can work together to improve the bottom line of your IT business. Stay positive, remain resilient, and live for today - and somehow, someway in the silence, common sense and sane solutions will emerge. Software measurement is one of these!

p.s., My newest book was published last week in Germany and is now available in the U.S.! Visit www.qualityplustech.com/books.html to read reviews and link to Amazon.com to order The IT Measurement Compendium: Estimating and Benchmarking Success with Functional Size Measurement.

Best wishes for resiliency and success,
Carol
http://www.qualityplustech.com/
http://www.caroldekkers.com/
Carol Dekkers, PMP, CMC, CFPS, P.Eng.
International software and systems industry expert on ISO standards, estimating, IT measurement. Consultant, Workshop leader, Speaker, Author.

-----------COPYRIGHT 2008 Carol Dekkers ALL RIGHTS RESERVED------------------------