Have you ever been invited to a party and then later un-invited? Well, something like this happened to me earlier in the week.
I received a personalized email from an IT industry journal telling me that because of my stature as an industry leader, I was being invited to attend their upcoming Premiere 100 IT Leaders Conference next month in Orlando, FL as their guest (and receive a complimentary $1795 valued pass to the conference) . I thought that their attendance was likely down this year due to financial times, and would want to boost their attendance by having industry leaders in their audience to further promote spinoff attendance.
I clicked on the registration link in the email, where they asked for further information so that they could process my invitation. THEN -- when I had filled out and submitted the registration form, -- the response screen said that my attendance would need to be APPROVED and that I would receive a confirmation email within hours. Excuse me? The journal management had invited me as their guest - why would someone need to approve me?
The promised email arrived only after I had sent a follow-up query - and, to my amazement - they denied my "Invitation". It seems that, despite my email address clearly indicating showing my company name, they had overlooked that I am an independent consultant who advises CIO's and other "C" level executives in large corporations about how to maximize their returns on their IT investments. I was now un-invited as their guest because I was not a senior IT executive employed by a big customer corporation (in other words an employee of a company who could be sold to by conference sponsors/vendors) - but, if I still wanted to attend, I could do so at a hefty new pricetag!
Maybe I am out of touch with the recessionary tactics that the industry journals such as this one use today, but it reeks of the tactics that banks use to lure people to their credit card programs -- you receive a "pre-approved" credit card application in the mail, only to be "rejected" due to the fact that they sent out a mass mailing of applications to everyone with an address. (Perhaps you remember when dogs , whose owners had opened a bank account in their name, received personalized pre-approved credit cards in the 1980's?) While this new mode of operation is a twist on the banking scheme, it is really the same tactic, and deserves the same the "bad taste in your mouth" response. The simple fact is that this industry journal didn't do their own homework - and prefers to invite "industry leaders" upfront, then un-invite them if they don't meet the demographic they had in mind on their guest list. This journal drops down several notches on my list for their haphazard way of treating IT leaders and subscribers. Their tactics of un-inviting in a bait and switch style of marketing is telling - this journal is interested purely in how much money they can wrestle from the hands of the IT world - not to impart knowledge or advance the industry as they purport.
Comments? Has anyone experienced a similar situation? It's really quite comedic in these recessionary times, and somehow I am reminded of the old Groucho Marx line: I don't care to belong to a club that accepts people like me as members.
Wishing you continued optimism - even on the most depressing of newsdays!
Regards,
Carol Dekkers
Carol Dekkers email: dekkers@qualityplustech.com
http://www.qualityplustech.com/
http://www.caroldekkers.com/
Contact Carol to keynote your upcoming event - her style translates technical matters into digestible soundbites, humorously and forthright.
View also Carol Dekkers' general blog at http://caroldekkers.wordpress.com/
============Copyright 2009, Carol Dekkers ALL RIGHTS RESERVED =============
Posted by Carol Dekkers Labels: Communication,
Thursday, February 19, 2009
Monday, January 26, 2009
The more things change... the more they stay the same
As I was perusing through about a year's worth of industry journals accumulating as they do in a pile in the corner of my office, I was hit with a flash of deja vu. Some of the journals hidden in the corners had actually been there for more than 24 months, and I was amazed to discover that this depression/recession/financial crisis we are in is not new. In fact, for the majority of years in this new millenium - we've been in a downturn!
This continuing trend - Information Week headlines from 2003 declared job hunting woes were in full swing back then - has been going on for years - albeit not in as dramatic as today - but the situation is not strikingly new. It's just taken us the aggregation of a pile of small things (and big things such as the Wall Street collapse) to realize the full gravity of the situation.
Having said this, there are two major thoughts that come to mind when we apply this same trend to software development:
1. This too will pass (it always does); and
2. The more things change, the more things stay the same.
Let me explain:
"This too will pass" - in the heat of our current crisis where software development budgets, projects, contracts, have been curtailed and layoffs announced, companies have reacted in the typical cocooning mode by burying their heads and cutting out any "superfluous spending" such as training, travel, conferences, process improvement and measurement. Yet, again and again, we know in our hearts and minds that this current crisis will pass and that this is the IDEAL TIME to invest (wisely) in just that very training to upgrade our workforces, exchanging information at conferences with best-in-class organizations, and investing strategically in process improvement and sustainable measurement initiatives so that we are ready, lean, and mean when the current situation passes (as it will). Corporations simply do not seem to learn, and instead of truly relying on the ingenuity and innovativeness of the America we know and love, they fall back on the scrimping and saving mode (like hiding money between mattresses) that worked for our forefathers but which has been proven to worsen (not improve) the competitiveness of a corporation when we come out of the current temporary crisis.
2. The more things change, the more they stay the same...
What I mean by this is that the more an industry finally embraces a particular concept, methodology, or newfangled approach, the more that nothing really changes. For example, take the current case of the adoption of agile methods of software development. While the proponents tout statistics based mostly on intuition and gut feel (proclamations such as agile is the only way to develop software today, bar none), the contrarians proclaim that the approach does not progress the industry but rather takes us back a step. They profess that agile is imperfect for all applications, do not provide a trail of quantifiable measurements, do not provide adequate documentation or commented code, and do not provide a solid system architecture to sustain the functionality into the future.
So what happens next? Following in the historical cycle, the current agile methods will begin to crumble (and be torn apart by some of the early adopters who now see the folly in some of the less disciplined aspects of the methodology), a "new and improved and evolutionary" approach will be devised and introduced, and the masses will go back to the tried and true (waterfall methodology) that does not work when agile is needed - and a new convincing and influencing cycle will start to convince the software development industry to try the new and improved "whatever approach".
So the more that things change, the more they seem to stay the same. Interesting culture of change n'est-ce pas?
This week I am facilitating a different set of workshops on Global Projects with Cultural Diversity and the question arose about the changing of a country's culture (such as India or China) based on the amount of outsourcing that is happening. While the pace of technology change can be rapid and pervasive, the change of a culture is extremely slow - proving again that the more things change, the more things stay the same.
Stay warm this February wherever you are (or cool if you are in Australia facing this month's record high temperatures of +40C!) - and have a good week.
I'll be back next week with more of the same - and a little bit of different! Happy development.
p.s., Here's a humorous photo from the icy streets of Santa Fe, NM during New Year's week this year. The Danger sign was missing a few letters.... Enjoy!
Regards,
Carol Dekkers
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 2009, Carol Dekkers ALL RIGHTS RESERVED =============
This continuing trend - Information Week headlines from 2003 declared job hunting woes were in full swing back then - has been going on for years - albeit not in as dramatic as today - but the situation is not strikingly new. It's just taken us the aggregation of a pile of small things (and big things such as the Wall Street collapse) to realize the full gravity of the situation.
Having said this, there are two major thoughts that come to mind when we apply this same trend to software development:
1. This too will pass (it always does); and
2. The more things change, the more things stay the same.
Let me explain:
"This too will pass" - in the heat of our current crisis where software development budgets, projects, contracts, have been curtailed and layoffs announced, companies have reacted in the typical cocooning mode by burying their heads and cutting out any "superfluous spending" such as training, travel, conferences, process improvement and measurement. Yet, again and again, we know in our hearts and minds that this current crisis will pass and that this is the IDEAL TIME to invest (wisely) in just that very training to upgrade our workforces, exchanging information at conferences with best-in-class organizations, and investing strategically in process improvement and sustainable measurement initiatives so that we are ready, lean, and mean when the current situation passes (as it will). Corporations simply do not seem to learn, and instead of truly relying on the ingenuity and innovativeness of the America we know and love, they fall back on the scrimping and saving mode (like hiding money between mattresses) that worked for our forefathers but which has been proven to worsen (not improve) the competitiveness of a corporation when we come out of the current temporary crisis.
2. The more things change, the more they stay the same...
What I mean by this is that the more an industry finally embraces a particular concept, methodology, or newfangled approach, the more that nothing really changes. For example, take the current case of the adoption of agile methods of software development. While the proponents tout statistics based mostly on intuition and gut feel (proclamations such as agile is the only way to develop software today, bar none), the contrarians proclaim that the approach does not progress the industry but rather takes us back a step. They profess that agile is imperfect for all applications, do not provide a trail of quantifiable measurements, do not provide adequate documentation or commented code, and do not provide a solid system architecture to sustain the functionality into the future.
So what happens next? Following in the historical cycle, the current agile methods will begin to crumble (and be torn apart by some of the early adopters who now see the folly in some of the less disciplined aspects of the methodology), a "new and improved and evolutionary" approach will be devised and introduced, and the masses will go back to the tried and true (waterfall methodology) that does not work when agile is needed - and a new convincing and influencing cycle will start to convince the software development industry to try the new and improved "whatever approach".
So the more that things change, the more they seem to stay the same. Interesting culture of change n'est-ce pas?
This week I am facilitating a different set of workshops on Global Projects with Cultural Diversity and the question arose about the changing of a country's culture (such as India or China) based on the amount of outsourcing that is happening. While the pace of technology change can be rapid and pervasive, the change of a culture is extremely slow - proving again that the more things change, the more things stay the same.
Stay warm this February wherever you are (or cool if you are in Australia facing this month's record high temperatures of +40C!) - and have a good week.
I'll be back next week with more of the same - and a little bit of different! Happy development.
p.s., Here's a humorous photo from the icy streets of Santa Fe, NM during New Year's week this year. The Danger sign was missing a few letters.... Enjoy!
Regards,
Carol Dekkers
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 2009, Carol Dekkers ALL RIGHTS RESERVED =============
Monday, December 8, 2008
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.
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 =============
(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 =============
Monday, December 1, 2008
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 =============
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 =============
Saturday, November 22, 2008
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 =============
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 =============
Saturday, November 15, 2008
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 =============
Saturday, November 1, 2008
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
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
Subscribe to:
Posts (Atom)
.JPG)
Posts
