Now that you have decided on a project and pulled together all of your documentation, you need to put together a compelling presentation.  I am going to assume that if you are an architect that you know how to put together and deliver a great presentation and avoid the common mistakes.  Even if you are an experienced presenter, I recommend reviewing some presentation tips.  I personally only have one major pet peeve when watching others present - reading the slides.  Please don't read the slides - I can read them myself.  I want to hear the story.

Prior to beginning your presentation the facilitator will ask you for a couple of technical depth areas.  This is meant to be a technology not a product - you would not pick BizTalk, you would choose integration technologies.  This certification is for an architect, not someone that is a specialist in a particular product.  Pick carefully the areas that you know well - not just the product you know well.

The thing to remember with the presentation is that it will be the only time during the board review that you are in control - the remainder of the review will be controlled by the board members.  Your job is to tell the story of your project in a fashion that will communicate how that scenario demonstrates that you meet the competencies of the MCA.  The trick is to tell it as a story - not as a rehash of what is in your documentation.  Here is a rough set of topics I suggest you might pull together your presentation:

• A little bit about you
• Information about the project
  • What business problem does the project solve and how does it accomplish that objective?
  • What is the reason that someone decided to spend money/resources on this particular project?
  • Who composed the team and what was your specific role on the overall team?
  • What was the timeline and budget?
• The project itself
  • How did you gather the requirements?
  • What tradeoffs did you make and why?
  • How did you ensure quality?
  • What type of methodology did you use and why?
  • What types of team/organizational challenges did you run across?
  • How was the project documented?
• The technology
  • Show me the overall architecture
  • What was unique from other projects?
  • What was challenging?
  • How did you know that the solution met the requirements?
  • What was your technical contribution?
  • Highlight something from your technical depth area.
• Deployment
  • How did you deploy the solution?
  • What did you do to ensure that the infrastructure of the solution met the appropriate requirements?
  • How will the solution be managed going forward (bug fixes, enhancements, changes to the infrastructure)?
• Project results
  • How did the solution perform against the original business justification?  Technical requirements?
  • What problems did you encounter after deploying?
  • What lessons did you learn?

Remember, you have 30 minutes to present - you will be cutoff at exactly 30 minutes so you need to ensure that you are getting your points across in an efficient manner.  I also recommend as you put together your personal outline, that you start to cross reference with the competencies published for the program.  Not just the high level competencies but also the sub-bullets. It is important to ensure you are showing the board how you meet the competencies.  However, you don't want to directly show how you meet the competencies - you want the board to come to that conclusion on their own.  I recommend that you do this through stories and anecdotes about the project.  For example, if you had a tough situation between two stakeholders you might discuss your role in that conflict and what you did in that situation.  If you had a junior development team, how did you bring them along to make them productive?  This is a much more interesting way to present yourself and is much more compelling to the board.

You don't have to cover every competency and every sub-bullet as part of your presentation.  In fact, it would probably be difficult to cover everything.  Just remember that the board will look at every competency and every sub- bullet and will ask you questions about ones you have covered and in particular the ones you did not cover.  If you provide strong evidence of meeting a specific area in your presentation, you may not be questioned on it later.

As you put together your presentation you should be aware of the "I" vs. "we" statements you make.  If you are like me, you tend to try to shine the light on the team and have become very accustomed to saying "we" around the accomplishments of the team.  This certification is about you - so don't be afraid to differentiate the times where you want to highlight your accomplishments instead of just the team.  The board is trying to understand your role and impact on the project, not just your ability to be a part of a functioning team.

You need to practice your presentation a few times beforehand and get your timing down and keep it under 30 minutes (I suggest you target 26-27 minutes just so you ensure you finish on time).  I don't advocate over practicing because it can take the passion out of the presentation.  You need to maintain your passion and excitement and if it becomes unnatural or rote the audience will know it.  You know your project and yourself well and you should be passionate about the subject.

This post is part of a series of articles about the MCA program.  The opinions here are solely my own and may not reflect the opinions of Microsoft or anyone affiliated with the MCA program.