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