There's a popular myth that says project process can't forecast the future. This is literally not a correct statement, since this phrase leaves out the confidence with which the future is being forecast.

Add to the counter arguments used many times about Black Swans (a book of the same name is either loathed or loved depending on you point of view). But Black Swans are not usually in the vocabulary of project management. We as project managers aren't managing portfolios of investment funds, forecasting earth quakes, or making other decisions in that.

We're taking Statements of Work, Requirements, Concepts of Operations, and turning them into plans and cost models. Emphasis here on "model." 

So the real question is

• How confident are we that our model is credible?
• Do we know anything about the underlying statistical behavior of this model?
• Can we ask probabilistic questions of the model?

By credible I mean, there is a confidence level that the model can be used to guide the work efforts. The answer to knowing the level of confidence starts with knowing something about the variance in the underlying random variables that make up the model. Pat Weaver talks about Dancing with Chance. Like all of Pat's posts, there is an associated paper with more details. Pat's site is a "Must Subscribe" in Google Reader.

But here's an issue with the word "Chance." Change is a probability term. The local weather forecaster uses the phrase "there is a 30% chance of snow tomorrow on the Front Range." This means there is a 30% probability to snow will occur over the forecast area. This does not mean there is a 30% chance it will snow at our house, since local weather conditions drive storms coming from the north (Wyoming) to dump huge amounts of snow here before reaching other parts of the Front Range. 

To know if it is going to snow heavily in Niwot, Colorado, we need to know both the probabilities and the underlying statistics of the behavior of the storm. In the same way we need to know the underlying statistics of the cost and schedule processes to know the probabilities of completing "on or before" for a "cost or less."

Probability Versus Statistics

In scheduling or cost when we speak of probabilistic outcomes - what's the probability of being on time and on budget - we also need to speak of the statistical nature of the activity network that models the durations and associated costs.

When we speak of a probabilistic activity network (a Bayesian network) we also need to speak in terms of probability.

A question that can be asked of the network is – “ what is the probability of completing this task by a certain date?”

But first we must asked – “what are the underlying statistics of the activities of the network?” Without this knowledge we cannot build a model (or at least a credible model) of the project's cost and schedule.

A final question that needs to be asked is “what is the inherent uncertainty in these estimates?” In other words – how good is our ability to guess in the presence of a statistical process? 

So to have a useful model of the schedule and cost and to avoid falling into the trap Pat suggests - having the illusion of control versus "managing in the presence of uncertainty."

What Does it Mean to Manage in the Presence of Uncertainty

Uncertainty in plain English is about the “lack of certainty.”

• Uncertainty is about the “variability” in the performance measures like cost, duration, or quality.
• Uncertainty is about the “ambiguity” associated with a lack of this clarity

Discovering the known and unknown sources of bias and ignorance helps define much effort it is worth to clarify the uncertainty. This is the underlying process driving uncertainty. As well, uncertainty arises from the basic processes of work.

• This is Deming uncertainty.
• It is the statistical “noise” built into the work process

Both of these sources of uncertainty impact cost and schedule.

• Trying to control the “noise” adds little value.
• Trying to control the “lack of certainty” arising from ambiguity and lack of clarity does have value.

We cannot "Manage in the Presence of Uncertainty" until we know about the statistics. What is the statistical population of allowable values of the random variables of duration and cost for a specific activity? If we don't know these from past performance, we can make inferences to get close.

Once we know about the statistics, we can ask Probability questions.

• What is the probability of completing on or before a specific date?
• What is the probability of this project costing a specific amount or less?

These are the questions that are asked an answered to move beyond falling into the trap suggested by Pat Weaver.

OK, so I finally created a Twitter account.

I might have done this earlier if there weren't some nitwit squatting the "ericsink" user name.  I considered registering as the National Waffle Institute and posting "French Toast Sucks" as my first tweet, but in the end I settled for "eric_sink".

I've been on Facebook for quite a while.  I apologize for turning down all the friend requests from blog readers, but I mostly just use Facebook for family stuff.  Unfortunately that means Facebook is a lousy place for me to make snarky comments about the technology world.  Most of my friends there either don't get it or don't care.

But Twitter should fill this hole in my life nicely.  Now, when it occurs to me that my German Shepherd is smarter, bigger and better-looking than Spolsky's husky will ever be, I can just let the world know immediately, and everyone will be better off.

At first I was worried about the length limit, but I've been practicing, and it is surprising how often 140 characters are enough.  For example, this one leaves plenty of room to spare:

Everything Borland ever created is now owned by someone who will destroy it.

But some of my practice tweets didn't go so well.  This one is way over the limit, but I could probably make the point without being so wordy:

Imagine what the software industry would be like if Bjarne Stroustrup had chosen a career with less potential for harm to the world, such as the intentional destruction of all tropical rainforests.

For me Twitter looks like a solution at the intersection of two problems.  With verbal remarks, it's easy to speak before thinking, but it just doesn't scale.  With blogging, I can reach lots of people, but I always end up thinking carefully before I post.  Twitter allows me to spew hasty, poorly-thought-out observations to a potentially worldwide audience.  I'm obviously a newbie, but that seems like a great feature.

There are 1000's of rules for managing projects. I've collected many over the past 3 decades of managing projects. I came across a web site that has important things to say about project and program management.

Altis is the site of Jerry Maden, Associate Flight Director, Goddard Space Flight Center. Jerry has his 100 Rules for NASA Project Mangers.

But there is a critical important rule his states regarding PM 2.0 type processes. I'll paraphrase

Spitzer's Advice for Business Leaders: Never write when you can talk. Never talk when you can nod. And never put anything in an e-mail.

This is expandable every aspect of managing a project.

Mathematics may be compared to a mill of exquisite workmanship, which grinds you stuff of any degree of fineness; but nevertheless, what you get out depends on what you put in; and as the grandest mill in the world will not extract wheat-flour prom peascods, so pages of formula will not get a definite result out of loose data.

in Quarterly Journal of the Geological Society of London, Volume 25, 1869, Lord Kelvin, when speaking of the calculations of the age of the earth, in Fourier Analysis, "The Age of Earth I, II, and III," T. W. Korner, Cambridge University Press, 1988.

In the article The Onion Uses Django, And Why It Matters To Us, a lot of interesting points are made about their ambitious infrastructure move from Drupal/PHP to Django/Python: the move wasn't that hard, it just took time and work because of their previous experience moving the A.V. Club website; churn in core framework APIs make it more attractive to move than stay; supporting the structure of older versions of the site is an unsolved problem; the built-in Django admin saved a lot of work; group development is easier with "fewer specialized or hacked together pieces"; they use IRC for distributed development; sphinx for full-text search; nginx is the media server and reverse proxy; haproxy made the launch process a 5 second procedure; capistrano for deployment; clean component separation makes moving easier; Git for version control; ORM with complicated querysets is a performance problem; memcached for caching rendered pages; the CDN checks for updates every 10 minutes; videos, articles, images, 404 pages are all served by a CDN.

But the most surprising point had to be:

Depending upon which academic study you read, the failure rate of complex IT projects is reported as being between 50% and 80%! I thought I'd test this against my own experiences and took a look back over my career at the number of complex systems I have worked on and how many could be counted as being successful. Clearly the first thing you need to do here is to define "complex" and also "success" so I'm defining complex as being a system with:

• Multiple stakeholders involved.
• Multiple systems interfaces.
• Challenging or high risk non-functional requirements (including delivery schedule and budget).

and "success" as being:

• Delivered on time and within budget.
• Met the stakeholders requirements.
• Went into production and ran for at least 12 months.

By my count I have worked on 18 projects which meet the first set of criteria and of those I reckon 8 meet the second set of criteria so can be thought of as "successful". So that's a slightly under 50% success rate! Not brilliant but within the industry average (which is of course nothing to brag about).
As you might expect there is a wealth of information out there on the reasons why IT projects fail. Top amongst these are:

• Lack of agreed measures of success.
• Lack of clear senior management ownership.
• Lack of effective stakeholder management.
• Lack of project/risk management skills.
• Evaluation of proposals driven by price rather  business benefits.
• Projects not broken into manageable steps.

These typical failings were highlighted in a joint British Computer Society/Royal Academy of Engineering report from 2004 called The Challenges of Complex IT Projects. That was six years ago and I wonder what has changed since then? Anecdotely I suspect not much. Certainly newspaper headlines about failed government IT projects of late (see, for example The Independent on 9th January 2010: Labour's Computer Blunders Cost £26bn) would seem to indicate we are still not very good at delivering complex systems.

The interesting thing to observe about the above list of course is that none of these problems are technical in nature, not directly anyway. Instead they are to do with governance and process (or lack thereof) and what you might term "soft" aspects of systems delivery, how we manage and understand what people want. One of the right-brain activities which we IT folk sometimes fail to exercise is "empathy". Our capacity for logical thought (i.e. left-brain activity) has gone a long way to creating the technological society we live in today. However in a world of ubiquitous information that is available at the touch of a button logic alone will no longer cut the mustard. In order to thrive we need to understand what makes our fellow humans tick and really get beneath their skin and to forge new relationships.

Happily this is not something that is easily outsourced, at least not yet! There is still something we can do as IT professionals therefore in engaging with stakeholders, understanding there wants and needs and trying to deliver systems that meet their requirements that can only be done with direct, personal contact.

My colleague J.K. has written an interesting blog post where he describes a slightly different approach that he's been taking to writing stories to help move the business value in a story towards the beginning of the description and avoid detailing a solution in the 'I want' section of the story.

To summarise, J.K.'s current approach involves moving from the traditional story format of:

As I...
I want.. 
So that...

To the following:

As I... 
I want..
By...

I quite like this idea and I've noticed that even without using this story format technical solutions are sometimes described as the business requirement and we need to look beyond the 'I want' section of the story card to find the real value and locate assumptions which have led to the story being written in that way.

To give a recent example, a colleague and I picked up the following story:

As the business
I want a HTTP module to be included on the old site
So that I can redirect a small percentage of traffic to the new site

We assumed that other options for redirecting traffic must have already been analysed and written off in order for this to be the suggested solution so we initially started looking at how to implement it.

After a bit of investigation it became clear that this was going to be quite an invasive solution to the problem and would involve re-testing of the whole old site (since we would be making a change there) before it could be put into production. That would take 2 weeks.

Speaking with Toni and Ashok about the problem it became clear that it should be possible to control whether traffic was going to the old or new site by changing the configuration in our load balancer, Netscaler.

Discussing this further we found out that this had been tried previously and hadn't quite worked out as expected which was why it hadn't been considered as an option.

We spent some time talking through using Netscaler with the network team and agreed to try it out on a performance environment and see whether it would balance traffic in the way that we wanted which it did.

We still need to make sure that it works as expected in production but it was an interesting example of how solutions can be excluded based on prior experience even though they might still be useful to us.

I'll certainly be more aware of noticing when a story details a solution and try and look for the actual requirement after this experience.

Competing pressures tempt one to believe that an issue deferred is a problem avoided, more often it is a crisis invented - Henry Kissinger

Remember risk management has five easy pieces

1. Hope is not a strategy
2. No single point estimate of cost or schedule can be correct without knowing the variance
3. Cost, Schedule, and Technical Performance are inseparable (this is the REAL Iron Triangle)
4. Risk management requires adherence to a well defined process
5. Communication is the Number One success factor in Risk Management

Ryan Enders has a post about using Social Media to help manage projects. Notice "help."

Ryan mentions what social media is being used in an article in PMI's PM Magazine. The referenced McKinsey study claims:

• 69% of respondents reported "gains in measurable business benefits."
• 10% improvement in operational costs
• 30% increase in the speed with which employees connect with outside experts.

The PMI article states

Depending on how they're used, social networking sites, blogs, and wikis can be powerful tools for intra-team collaboration.

All this collaboration stuff is critical to project success. But is collaboration using the latest social media tools "project management."

Let's quickly review the knowledge groups of Project Management.

1. Project Integration Management
2. Project Scope Management
3. Project Time Management
4. Project Cost Management
5. Project Quality Management
6. Project Human Resource Management
7. Project Communications Management
8. Project Risk Management
9. Project Procurement Management

Now social media as a communication enabler can add value to the communication needs of these process groups. This is not new news. Even in our defense and space practice, we live on IM and SharePoint. Both might be categorized as Social Media. Team Sites, chats with people at multiple locations, document control, dashboards, WebEx, and other "connection tools."

But are these tools Project Management?

They support the management of the project, no doubt. But so did the HP9000 based electronic contract management and program management tools used at Hughes Aircraft for the AH-64 in late 1970's, described in Project Management Lessons Learned.

Was this called PM 2.0? Was it social media? There was chat across the terminals with remote vendors. There was collaborative development of documents and databases between multiple sites using the tools of the HP9000 (a wonderful machine with a very fast processor).

Project Status Updates using Twitter

As a emeritus program was fond of saying,

"Are you out of your ever lov'in mind."
You might as well scratch your project status on the wall of the men's stall.

First project status is ALWAYS a report of physical percent complete against the planned percent complete. This is a number, some percentage, which can certainty be sent bu email, IM, twitter, and even scratched on the stall.

But that's not the "status" of the project. That the physical percent complete at the end of the reporting period - weekly in our domain.

The status of the project is the face to face, or video face-to-face conversation between live people about how you got to that physical percent complete, what prevented you from reaching the planned physical percent complete, and what you're going to do to get back to GREEN for the next assessment of your physical percent complete.

The Core Paradigm Gap

Reporting a numeric value is not "Project Management." No matter how you restate the hype, chatting, twittering, posting docs in MOSS, looking at pictures on WebEx is not "managing the project."

It's exchanging information about the project - possibly. Exchanging information through a very narrow bandwidth channel. And since the channel is narrow, communication errors are mandatory.

Those suggesting PM2.0 of the next big thing have failed to understand that a successful PM relies heavily on face-to-face communication. The agilest know this and state this in their Agile Manifesto.

So how is it we've moved away from this fundamental understanding? I have some conjectures:

• Those conjecturing PM 2.0 don't actually manage projects, they develop software. And since PM 2.0 is a project tool, they assume those of us who manage projects will really like their tool.
• That the core understanding of the process areas and knowledge groups of PMBOK and similar items in other PM framework are either not understood, nor practiced, and both in the world the PM 2.0.

Show Me the Money - Ron Tindell to Jerry McGuire

Please show me in units of measure meaningful to our clients (Enterprise IT, US DoD, DOE) for "managing" projects with tools like twitter, IM, and other "social media."

Kiron D. Bondale posted about the Seven Deadly Sins of project scheduling. After you read this very useful post here's my experience of putting this advice to work in ways you'd see if you were on the site of one of our defense programs.

1. Scheduling Tools are necessary but not sufficient - we use MindJet to capture the Work Breakdown Structure (WBS), the Integrated Master Plan (IMP), and the Work Packages under the IMP's Accomplishment Criteria. The structure of the IMP/IMS can be seen here. The WBS is similar. The great thing about MindManager, is the "export to Project" button. Once you get close to what you want, just export the map to Project and continue working. When the WPs are sequenced, this is called the Integrated Master Schedule (IMS). The details inside the WPs are supplemental schedules held by the WP Manager. In other domains there are Tasks under the Accomplishment Criteria.
2. Scheduling constraints are forbidden in any credible schedule. Just don't use them, period. The only constraint should be Must Start On (MSO) for the milestone titled "Authorization to Proceed" (ATP). All other constraints are As Soon As Possible. You should avoid like the plague leads and lags. In some of our defense domains (NAVAIR, the Navy's aviation division) not leads or lags are allowed longer than 5 days. On a large program 5 days is the same as zero days. If you need leads or lags, make a "holding task," label it as a "holding task," and put it between the two tasks you want to lead or lag.
3. Automated resource leveling is an oxymoron, used by morons. Do not let a machine do your work for you. Touch every resource issue. Confirm the resources are what you need, their availability and what they are capable of doing. In some organizations there is a separate "resource management planning tool. Use it. NEVER let MSFT Project do this, it simply screws uop the entire IMS. This is a transition to the topic of Work Packages (WP). WP's are resource loaded but resource leveled. The WP manager figures out how many people she needs over what period of time. Then looks after assigning them work inside that period of performance.
4. Too Many Tasks - use Work Packages to collect detailed work. In formal scheduling domains, changes to the schedule go through change control. There is no way anyone can know what work is going to be done at the detailed level in 6 months. Or even in 2 months, let alone 18 months. Work Packages collect these tasks and the assigned staff and define a period of performance, the tangible outcomes of the work effort. the WP manager looks after the details. Put the WP in the schedule as a "task." For future work create a Planning Package (PP), with a period of performance, forecast resource loads. This WP and PP is the standard in the US DoD Earned Value Management approach. Don't let anyone talk you out of this. Make thew WP manager accountable. The PM can then see physical progress without all the gory details of tasks. Push responsibility down. Make the PM accountable. 
5. Out of Date Schedules - if you don't status your schedules every week, you should look for a new job. On large - I mean billions of $'s manned spaceflight programs - we status the schedule every Thursday afternoon in preparation for the "stand up" meeting on Monday to answer the question "what have you done for me lately?"
6. Outline Levels - match the structure of the Work Packages that sit at the bottom of the Integrated Master Schedule (IMS), shown in the notional picture here. The construction of the IMP/IMS is more subtle that a narrow bandwidth blog can deal with. But, the indent structure of the IMS should only go to level 5 - Program Event or Major Milestone, Significant Accomplishment, Accomplishment Criteria, Work Package or Planning Package, and maybe a sub-WP. Details are in the Work Package. The WP can be no longer than 60 calendar days for big projects.
7. Starting Over - once the Performance Measurement Baseline is "set," making changes means a change control process. The way out of a continuous change process is to use Rolling Waves. Planning Packages are in the the "out years," Work Packages in the current (active) Rolling Wave. Future Rolling Waves contain the remaining budget, define the future deliverables at a macro level and always have a critical path through them to the end of the project. But the details are defined yet. So as the requirements emerge (become definitized as we say), then the actual contents of the Planning Packages in the future Rolling Waves also becomes definitized. What this avoids is having to replan the work that never should have been planned in detail in the first place

When I interview people for a job position, I always ask them if they have any questions for me.

But they rarely have. Some candidates even look surprised.

Why?

A job is an economical relationship between you and your manager. What you bring to the table are knowledge, skills, and experience. What your manager offers are a salary, interesting projects, and a great working environment.

Both of you should be asking each other questions!

Here are some questions, off the top of my hat:

1. What do know about management? What models do you use?
2. What books and blogs do you read? Which managers are your source of inspiration?
3. Are your teams self-organizing? How? And how do you add value?
4. Can you give examples of your teams being happy about what you've done for them?
5. How have you motivated your team members?
6. What kind of direction, rules and constraints do you impose on teams?
7. What kinds of impediments have you removed lately?
8. How do you develop competence and craftsmanship in the teams?
9. Am I free to use social tools and networks, like Twitter and Facebook?
10. Can I have business cards without a job title printed on it?

Can you think of some more?

Trust in a business environment can only be achieved when both parties in an economical relationship ask the right questions, and give satisfying answers.

Never be the only one to answer questions!

You know what? Next time when you don't ask me questions, I'm not even going to hire you.

(picture by Stefan Baudy)

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo';
Latest, greatest and favoritest posts:
Fix the Small Problems First
Doing What Matters, No Matter What
If You Want Something Done, Practice Your Patience

When I interview people for a job position, I always ask them if they have any questions for me. But they rarely have. Some candidates even look surprised. Why? A job is an economical relationship between you and your manager.... Jurgen Appelo

If sending email is a critical part of your online presence, then it pays to look at ways to enhance the probability that messages you send will find their way into your recipients' inboxes, as opposed to their spam folders. This is fairly hard to achieve and there are no silver bullet guarantees, but there are some things you can do to try to enhance the reputation of your mail servers.

One thing you can do is use DKIM, which stands for DomainKeys Identified Mail. DKIM is a result of a merging between Yahoo's DomainKeys and Cisco's Identified Internet Mail. There's a great Wikipedia article on DKIM which I strongly recommend you read.

DKIM is a method for email authentication -- in a nutshell, mail senders use DKIM to digitally sign messages they send with a private key. They also publish the corresponding public key as a DNS record. On the receiving side, mail servers use the public key to verify the digital signature. So by using DKIM, you as a mail sender prove to your mail recipients that you are who you say you are.

Note that DKIM doesn't prevent spam. Spammers can also use DKIM, and sign their messages. However, DKIM achieves an important goal, which is to prevent spammers from spoofing the source of their emails and impersonate users in other mail domains by forging the 'From:' header in their spam emails. If spammers want to use DKIM, they are thus forced to use their real domain name in the 'From' header, and this makes it easier for the receiving mail servers to reject that email. See also 'Three myths about DKIM' by John R. Levine.

As an email sender, if you use DKIM, then your chances of your mail servers being whitelisted and of your mail domain being considered 'reputable' are increased.

Enough theory, let's see how you can set up DKIM with postfix. I'm going to use OpenDKIM and postfix on an Ubuntu 9.04 server.

1) Install prerequisites

# apt-get install libssl-dev libmilter-dev

2) Download and install OpenDKIM

# wget http://downloads.sourceforge.net/project/opendkim/opendkim-2.0.1.tar.gz
# tar xvfz opendkim-2.0.1.tar.gz
# cd opendkim-2.0.1
# ./configure
# make
# make install

You will also need to add /usr/local/lib to the paths inspected by ldconfig, otherwise opendkim will not find its required shared libraries when starting up. I created a file called /etc/ld.so.conf.d/opendkim.conf containing just one line:

/usr/local/lib

Then I ran:

# ldconfig

3) Add a 'dkim' user and group

# useradd dkim

4) Use the opendkim-genkey.sh script to generate a private key (in PEM format) and a corresponding public key inside a TXT record that you will publish in your DNS zone. The opendkim-genkey.sh script takes as arguments your DNS domain name (-d) and a so-called selector, which identifies this particular private key/DNS record combination. You can choose any selector name you want. In my example I chose MAILOUT.

# cd ~/opendkim-2.0.1/opendkim
# ./opendkim-genkey.sh -d mydomain.com -s MAILOUT
# mkdir -p /var/db/dkim
# cp MAILOUT.private /var/db/dkim/MAILOUT.key.pem

The opendkim-genkey.sh script generates a private key called MAILOUT.private, which I'm copying to /var/db/dkim/MAILOUT.key.pem. It also generates a file called MAILOUT.txt which contains the TXT record that you need to add to your DNS zone:

# cat MAILOUT.txt
MAILOUT._domainkey IN TXT "v=DKIM1; g=*; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADGTeQKBgQDATldYm37cGn6W1TS1Ukqy2ata8w2mw+JagOC+GNEi02gvDyDtfTT0ivczPl45V1SqyQhdwF3dPnhkUXgxjjzBvU6+5uTFU4kzrKz0Ew7vywsCMcfKUjYhtVTAbKAy+5Vf3CNmOlFlJnnh/fdQHVsHqqNjQII/13bVtcfYPGOXJwIDAQAB" ; ----- DKIM MAILOUT for mydomain.com

5) Configure DNS

Add the generated TXT record to the DNS zone for mydomain.com.

6) Configure opendkim

There is a sample file called opendkim.conf.sample located in the root directory of the opendkim source distribution. I copied it as /etc/opendkim.conf, then I set the following variables (this article by Eland Systems was very helpful):

Canonicalization relaxed/simple
Domain mydomain.com
InternalHosts /var/db/dkim/internal_hosts
KeyFile /var/db/dkim/MAILOUT.key.pem
Selector MAILOUT
Socket inet:9999@localhost
Syslog Yes
UserID dkim
X-Header yes

Note the InternalHosts setting. It points to a file listing IP addresses that belong to servers which use your mail server as a mail relay. They could be for example your application servers that send email via your mail server. You need to list their IP addresses in that file, otherwise mail sent by them will NOT be signed by your mail server running opendkim.

7) Start up opendkim


# /usr/local/sbin/opendkim -x /etc/opendkim.conf

At this point, opendkim is running and listening on the port you specified in the config file -- in my case 9999.

8) Configure postfix

You need to configure postfix to use opendkim as an SMTP milter.

Note that the postfix syntax in the opendkim documentation is wrong. I googled around and found this blog post which solved the issue.

Edit /etc/postfix/main.cf and add the following line:

smtpd_milters = inet:localhost:9999

(the port needs to be the same as the one opendkim is listening on)

Reload the postfix configuration:

# service postfix reload

9) Troubleshooting

At first, I didn't know about the InternalHosts trick, so I was baffled when email sent from my application servers wasn't being signed by opendkim. To troubleshoot, make sure you set

LogWhy yes

in opendkim.conf and then inspect /var/log/mail.log and google for any warnings you find (remember to always RTFL!!!).

When you're done troubleshooting, set LogWhy back to 'no' so that you don't log excessively.

10) Verifying your DKIM setup

At this point, try to send email to some of your email accounts such as gmail, yahoo, etc. When you get the email there, show all headers and make sure you see the DKIM-Signature and X-DKIM headers. Here's an example from an email I received in my GMail account (you need to click the 'Reply' drop-down and choose 'Show original' to see all the headers):

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mydomain.com;
 s=MAILOUT; t=1269364019;
 bh=5UokauIClLiW/0JovG5US3xUr2LcjGTnutud9Ke1V2E=;
 h=MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID:
  Subject:From:Reply-to:To:Date;
 b=X7cgUltyjJpqN7xavEHPrLSTnEqyj7fsuS/4HDrs3YfZg2d8K9EdvqJ5gwdrmkVEL
  M27ZDugI0yaK5C+cdOZ2Fyj8nG83nLwcnMz7X3EqCkHP0CPlv9FCXtjispxLJ2W3xc
  AUQnp4vVChYb/TEGmQV+Ilzzf9a9WDUMhWlaljjM=
X-DKIM: OpenDKIM Filter v2.0.1 mymailserver 4B4B864925

That's about it. There are quite a few moving parts here, so I hope somebody will find this useful.

This is still not an official information but the location and date for GTAC 2010 has leaked (and boy don’t we love leaks in Software Testing … Ok, that was easy …). The location had actually already leaked at the end of GTAC 2009 and I was sharing it with you during my GTAC 2009 field report. The confirmation has been given by Patrick Copeland himself as part of the GTAC group distribution list. The location will be Hyderabad, India and it looks like it will be held the week of October 25th ! With the large community of testers in India, I can’t think of a better place to hold this event !

GTAC 2006 and 2007 were focused on general test automation. GTAC 2008 theme was SaaS and last year the main topic was testing for the web. What would be the direction for GTAC 2010? I love games, and I have to play that one ! I think the main theme will be:

TESTING FOR THE REAL-TIME WEB.

This is a general trend for 2010 and I think a lot of software testing team will have to be very creative to handle the real-time aspects of these new web application. I see a few type of application we’ll have to deal with:

Real-time collaboration

Every major vendor is coming up with its own real-time collaboration suite for the Enterprise
Google Wave
SAP StreamWork
Oracle Beehive
Microsoft Unified Communications
Novell Pulse
And these are only the major vendors. You have a lot of startup riding on that wave.

Real-time CRM

This cover Real-time analytics, real-time data integration and real-time intelligence. That’s a big trend within the CRM space as well as in web analytics. There is more and more need to track your customer or website visitor behavior in real-time in order to make business decision rapidly, change your marketing/ad campaign on the spot, detect fraud etc.

Real-time search

Obviously a really strong trend in 2010 with services from Google and Microsoft of course but also from smaller company such as Tweetme, oneriot, topsy, scoopler etc.

Real-time Social network

Obviously Facebook is the major player here but you can expect a lot of competition in that space in 2010. Google has launched the hostility with Google Buzz. Who’s next? Expect also a lot of Enterprise solution such as Salesforce Chatter.

Real-Time location based application

This market is going to explode in 2010 with smarphones and GPS device getting smarter everyday. Foursquare is leading the way right now but there are many other application available. My bet is that real-time location based advertisement is going to explode as well … When you know that Google was awarded a patent for location-based advertising last month, it’s an easy bet to win !

So testing for the real-time web is my bet for GTAC 2010. I can easily see a few additional interesting topics to cover especially around cloud computing which is really hot as well. It would be good to get presentation from people doing testing from the cloud, what are the implications, benefits, challenges etc. I wouldn’t mind seeing Tom Lounibos on the stage to share with us the good stuff he’s doing with Soasta ! I had the opportunity to see a demo of their platform and it is really impressive !

I sure hope I’ll have an opportunity to join the party in October !

Related posts:

1. GTAC 2009 field report
2. GTAC 2009 in Zurich
3. GTAC 2009 – Call for attendance
4. Cloud computing services are hot in 2009 !
5. Software Testing conferences and webinars – Where to find them ?

A deployment package arguably is never just a single file to be dropped somewhere and you are done. No! Choosing and bundling your artifacts for deployment is none less complex than figuring out an efficient deployment strategy itself. The Java EE specification suggests EARs as the standard packaging and distribution mechanism but we all know [...]

Imagine God creating the world in a waterfall way.... I then, picture God behind a big desk, discussing with all the angels about how Earth could look like.   What animals should be created?, How long should it take to go from complete darkness to complete daylight?  What colors will we use ?.... After [...]

I’ve mentioned the use of MBT in evaluating requirements in an earlier post. The last few days I had an interesting mail conversation with Joost Jongman (@jjongman), an intern with us a Sogeti. The conversation was about how I see the use of MBT. He responded on some remarks I made on Twitter, this blog [...]

A fairly common scenario that we come across when building automated test suites using Selenium is the need to get past the security exception that Firefox pops up when you try to access a self signed HTTPS page.

Luckily there is quite a cool plugin for Firefox called 'Remember Certificate Exception' which automatically clicks through the exception and allows the automated tests to keep running and not get stuck on the certificate exception page.

One other thing to note is that if the first time you hit a HTTPS page is on a HTTP POST then the automated test will still get stuck because after the plugin has accepted the certificate exception it will try to refresh the page which leads to the 'Do you want to resend the data' pop up.

We've previously got around this by writing a script using AutoIt which waits for that specific pop up and then 'presses the spacebar' but another way is to ensure that you hit a HTTPS page with a GET request at the beginning of the build so that the certificate exception is accepted for the rest of the test run.

To use the plugin in the build we need to add it to the Firefox profile that we use to run the build.

In Windows you need to run this command (having first ensured that all instances of Firefox are closed):

firefox.exe --ProfileManager

We then need to create a profile which points to the '/path/to/selenium/profile' directory that we will use when launching Selenium Server. There is a much more detailed description of how to do that on this blog post.

After that we need to launch Firefox with that profile and then add the plugin to the profile.

Having done that we need to tell Selenium Server to use that profile whenever it runs any tests which can be done like so:

java -jar selenium-server.jar -firefoxProfileTemplate /path/to/selenium/profile

"The system is finite, therefore trivial"

What Can Be Automated, Bruce W, Arden, Cambridge, MA, 1980

Josh Nankivel has a post on his PMStudent site about the Critical Path. This presentation is one of those "let  me re-examine the obvious." This worth the time to watch, but it brings out several issues in the domain of project and program management.

Some of the questions asked by the author include:

• Where does the CP begin and end?
• CP start and end on date constraints? 
• Fixed completion of intermediate milestone impact the CP?

But first you must watch the presentation to connect with the comments below.

But first a pre-apology. This topic is wickedly obtuse for all the right reasons. So this very narrow bandwidth blog channel is replaced in practice with a 3 day workshop, and continuous hands on mentoring, coaching, and keyboarding for the programs we work  using Monte Carlo Simulation.

If you'll go to the Lijit search box on the right panel of this blog and enter "monte carlo" you'll see the tip of the ice berg of this topic.

This discussion starts with a primary problem

When you put hard constraints in the middle of the schedule, you have essentially "broken" the schedule. In Murry Wolf's presentation, complexity is created by this approach.

In our defense domain, hard constraints such as Must Finish On (MFO), Finish Now Later Than (FNLT) are strong discourages in principle and in practice ruin the use of Monte Carlo Simulation, since the probabilistic finish date are now anchored in the schedule and cannot move.

Here's the Real Problem

In our domain, the notion of the Critical Path as an "entity" that exists in the schedule, is replaced by a probabilistic assessment of the confidence of completing on or before a planned date. This is the role of the Monte Carlo Simulation of the schedule.

This approach removes all the hand waving, re-definition of terms, and arguing what is meant by Critical and Path.

The identification of the paths the impact the confidence of a deliverable is called the cruliality of the schedule. Using Wolf's classification are useful however:

• Acute Path - this is a path through the schedule that has negative slack that will substantially impact a deliverable
• Watch Path - this is a path through the schedule that needs to be corrected so the deliverable can be made as promised
• Free Paths - are paths that have positive float

This is an interesting view from Construction

At one time I was a member of the College of Scheduling. But the construction paradigm did not sit well with me for a few reasons:

• The litigation support issues dominate the style of scheduling. In the defense world, the Integrated Master Plan is "on contract." The Integrated Master Schedule (IMS) is subject to change of course - through a change control process - but the contributes to the IMS - the Integrated Product Teams (IPT) have similarly "promised" to deliver on time, on schedule.
• Litigation is rare and usually takes place after some complete disaster occurs.
• The use of constraints is common and remove the ability of Monte Carlo Simulation.

It's the Monte Carlo Simulation that got me hooked on the method of doing the IMP/IMS. The IMS in the defense world MUST have minimum constraints. The DCMA 14-Point Assessment sets the upper limit of constraints.

To answer Mr. Wolf's pressing question - "which paths should we be looking at," means answering the cruciality question with a Monte Carlo model.

Cruciality is the combination of criticality and sensitivity of the drivers of the deliverables. That is what activities drive the "lateness" of the deliverable, how sensitive is this lateness and how critical are they?

That's how you answer all confusion created by constraints, multiple critical paths - which are always there in any real schedule, since the durations are random numbers - and the identification where to look for the next "emerging" problem with staying on schedule.