Microsoft Dynamics Sure Step – Overview of Phases

I recently passed ‘Exam MB5-705 Managing Microsoft Dynamics Implementations’ so I thought I would draft a blog post or two to provide an overview of the Microsoft Sure Step Methodology. For this post, I will provide a high level overview of the phases within Sure Step.

Microsoft Dynamics Sure Step is a full customer lifecycle methodology for all Microsoft Dynamics solutions. This includes Microsoft Dynamics CRM, but also all of Microsoft’s ERP (Enterprise Resource Planning) solutions including:

The methodology provides guidance, tools, templates and best practices to help increase the consistency, quality and success of Microsoft Dynamics engagements.

Sure Step has 6 phases, and while the approach, activities and specific deliverables depend on which ‘project type’ (e.g. ‘Standard’, ‘Enterprise’, ‘Rapid’, ‘Agile’ or ‘Upgrade’ – more on these in a future post) you’re implementing, the next section will cover the Sure Step phases in broad strokes.

Sure Step phases

Diagnostic Phase

Diagnostic phase

The Diagnostics phase is the only phase within ‘Solution Envisioning’. Its objective is to understand the high level solution requirements in order to help the customer determine the right solution to meet their needs. The Diagnostic/Solution Envisioning phase begins with the ‘Solution Overview’; an overview of the various MS Dynamics products and their capabilities. This is followed by the (optional, though highly recommended) ‘Decision Accelerator Offerings’, designed to assist the customer through their due diligence and decision making process and greatly reduce the risk when for selecting a new CRM or ERP solution.

The decision accelerators are typically low-cost, one-to-four week engagements that help the customer understand the ‘degree-of-fit’ between their needs the available solutions, before making a major investment. The decision accelerator offerings include:

  • Accelerated Proof-of-Concept (POC) with CRM Online
  • Requirements and Process Review
  • Fit Gap and Solution Blueprint
  • Architecture Assessment
  • Scoping Assessment
  • Proof of Concept (POC)
  • Business Case
  • Upgrade Assessment

The Diagnostic phase typically concludes with customer acceptance of a high level project charter and project plan as well as a clear understanding of the business drivers and key metrics for the project to unite the team behind a common vision for proceeding to the implementation phases.

Analysis Phase

Analysis phase

The Analysis phase represents the official beginning of the project implementation. Using the outputs from the earlier Diagnostics phase (e.g. reports from the decision accelerator offerings, high level project charter), this phase defines the activities required to initiate and effectively plan the rest of the project. A few of the milestones and deliverables typical in the analysis phase are:

  • Project kickoff meeting
  • Project plan and charter
  • Risk and Issues register
  • Fit/Gap Spreadsheet
  • Functional Requirements Document (FRD)
  • Business Process maps/workflows
  • Data migration requirements
  • User Training Requirements
  • Environment specification

This phase culminates with the customer’s approval on the documented requirements, as the basis of the scope for the implementation. Sure Step advocates for formal ‘toll-gate’ reviews at the end of each phase – including the Analysis phase – to ensure that the milestones and deliverables have been provided as per the earlier agreed quality standards and that any risks and issues are proactively addressed before proceeding into the next phase.

Design Phase

Design phase

The focus of the Design phase is to define how the business requirements will be implemented. Using the outputs and deliverables from the previous Analysis phase as inputs, the design phase is where the various design documents are created for use by the implementation team to build the solution. These design document deliverables include:

  • ‘Fit’ Design Document – to document the configuration and settings required to fulfil requirements deemed as ‘fits’ during the Fit-Gap analysis performed during the earlier phases.
  • ‘Gap’ Design Document – to document the design of the custom code required to meet customer requirements deemed as ‘gaps’ during the Fit-Gap analysis.
  • ‘Technical’ Design Document – the purpose for this 3rd design document is to design and document the technical details of each system modification or enhancement. This document includes items such as user interface design, security as well as business and data layer components.
  • ‘Solution’ Design Document – this document provides the overall solution description in business language and includes the capabilities being abled by the solution

These documents provide the roadmap for development and reflect the approved customer requirements for implementation.

The design phase is also when the non production environments (e.g. development and test) are set up to support the configuration and customization work. Core team training is also completed in the design phase, beginning the knowledge transfer process to the customer.

Project Management continues to play an important role in the design phase through activities including updating of project plans as required based on the approved designs and associated timelines, as well as change control management, communication, status reporting and financial management.

Development Phase

Development phase

The development phase is where the implementation team will build the system components defined and approved in the design phase, including configurations, customizations, integrations and interfaces and data migration processes. The development phase is also where the solution is fully tested by the project team before the customer performs their user acceptance testing (UAT) in the Deployment phase. Solution testing includes process testing, integration testing as well as data acceptance testing.

The development phase is also where the infrastructure team completes the production environment specification and provides to the customer so that they can start the procurement process for necessary hardware and software components.

Training documentation is completed in the development phase as is the creation of UAT scripts that the customer will use in the subsequent phase for their testing and acceptance activities.

Project risk management is an important facet of the project management activities at this (or any) stage of the project, to ensure that risks and issues are being monitored and analyzed, with mitigation and contingency plans being created accordingly.

Deployment Phase

Deployment phase

The deployment phase is where the solution ‘goes live’, but there is much more to it than that. As noted in the development phase, the deployment phase is where the user will perform their testing and acceptance activities to validate that all of the requirements for the project have been satisfied. Prior to this step, the customer has to be trained on the system – as adequate training is one of the most important steps in any successful implementation.

The user training aligns closely with Organizational Change Management activities that would have been executed all throughout the project phases [more in a future post] in order to ensure that the users are not only trained on the new system but are also fully aware of all of the business drivers and benefits being brought about as a result of the implementation.

Sure Step recommends short, directed training sessions that begin with a broad overview and then narrow to a role-based approach specific to business processes and job tasks for the various role types. Sure Step also recommends conducting the training as close to go-live as possible in order to mitigate against knowledge erosion.

When all training has been completed and all deliverables have been completed and signed off, the solution is deployed to the production environment and transitioned to the operations team.

Operation Phase

Operation phase

The operation phase is where any final activities to officially close out the project are performed and where the solution is officially transitioned to the customer including providing any remaining knowledge transfer. Additional activities and deliverables include a final project closure report, provided to the customer for sign off and a project closure meeting to discuss and document project lessons learned.

This has been a high level overview of the phases within the Microsoft Dynamics Sure Step methodology. I will focus on other aspects of the methodology in future posts.


Leave a comment

Filed under Project Management

The Many Shapes of Project Management


If you’re at all familiar with Project Management, be it in an IT context or otherwise, or have the great fortune to have a Project Manager in your family or circle of friends, you may have heard of the ‘Triple Constraint’. Sometimes also referred to as the ‘Iron Triangle’ of Project Management, the Triple Constraint has been the de facto framework to illustrate the tradeoffs faced by Project Managers since the dawn of time.

With ‘scope’, ‘time’ and ‘cost’ as the 3 ‘constraints’, (with ‘quality’ often shown in the middle), the triangle metaphor is used to illustrate that a change on any one of these items will invariably result in an impact on one or more of the others. A couple of examples might include:

  • Adding a new feature or additional complexity to an existing feature (an addition to ‘scope’) will result in additional time and/or costs.
  • Delivering to an accelerated schedule (a change in ‘time’), you may need to add additional resources which will drive additional ‘costs’ (or require you to figure out areas of ‘scope’ that can be cut).
  • And on and on it goes.

While the traditional triple constraint/iron triangle provides the basic, ‘Project Management 101’ framework for managing projects, it of course doesn’t tell the whole story. What about risks and issues? What about client and stakeholder expectations? What about resource management and communications? And more…

Further to this – and thinking more broadly – what about things like ‘time to market’ of the product or service you are developing, or ‘adoption rate’ of the product or service. Do these things matter? Ultimately, the question is – in today’s environment, does delivering a project ‘on time’, ‘on schedule’, ‘on scope’, with an acceptable level of ‘quality’, make it a successful project?

As you might expect, there is some level of debate and discussion around this in the Project Management community. As such, the traditional Iron Triangle has given way to a number of derivatives of the original to try and incorporate some of the above noted shortcomings. Some of the many ‘shapes’ out there include hexagons, stars, parallelograms (the ‘Iron Parallelogram’ doesn’t roll off the tongue quite as easily as triangle) and more, but the one that seems to have gained the most traction is the ‘Project Management Diamond’ where ‘quality’ has been upgraded to an equal to the others and ‘expectations’ now sits in the middle.


While the intention isn’t that the particular ‘shape’ capture every single thing that a Project Manager needs to balance (as that would certainly be an ugly shape), there are still a few factors that I would propose might be worthy of inclusion from my perspective.

Keeping with the triangle shape, I might propose an inverted triangle that overlays the original triangle, to augment what’s already in place in order to add some ‘real-life’ factors that tend to also factor into projects, since as most Project Managers would probably agree, if all they had to manage were ‘scope’, ‘time’ and ‘cost’ – what a wonderful world it would be!

double triangle

Before proceeding further I should note that the facets of this model are not ‘constraints’ on their own (in case that much wasn’t obvious), but rather, important and interrelated elements in project engagements; the constraint lies in the challenge Project Managers and teams have in managing all of the trade-offs, considering all of the interrelations at play.

Client Factors

When it comes to delivering ‘successful’ projects, there are a number of client factors that tend to not get reflected in the models and metaphors that we see in Project Management literature. A few of these things include – how well a client understands their own business process, in order to be able to articulate them to your team during the requirements phases, or how well resourced the client team is in order to meet deadlines that are dependencies for the success of your project (i.e. securing environments, performing user acceptance testing etc.).

Other important client factors include a client’s understanding and adherence to processes (that should be) outlined in project SOWs and charters that relate to scope and change management, as well as how well they plan and execute internal change management activities to ensure organizational and user buy-in and adoption.

Team Factors

Similar to the client factors noted above, there many team factors that are not often spelled out in detail in the PMBOK and other Project Management resources. A few such examples include – whether or not the team put forth to deliver the project has the necessary skillsets and experience on the platforms and technologies being used, or whether the team members have been allocated at a high enough percentage to actually deliver to the agreed upon schedule.

Another important team factor (quite arguably the most important factor) relates to the individuals that make up the team and what makes each of them tick. What tools and technologies do they prefer to work on? How do they like to work? Are they an introvert or an extravert? Are they motivated more by intrinsic or extrinsic factors? And how much control do Project Managers have over being able to provide the conditions to optimize the team’s performance and experience on the project?


When it comes to processes, how much is enough? How much is too much? What is the best way to ensure team members have autonomy over their work, while also providing them with a sufficient amount of support and resources to succeed?

Also, how best to balance the need to shelter the team from distractions so they can focus on their deliverables, with ensuring that they have had sufficient inputs into plans that they will be held accountable to, and with ensuring the Project Manager is armed with the inputs he or she needs to represent the team for status reporting and communications?

Other things to consider in the realm of process might be: how well does your process adapt to different project types, different technologies, cross-business unit engagements and remote/distributed team scenarios? There are no answers that will be right all of the time in all situations (but chime in if you have them and would like to share), but figuring out the right processes and right amount of rigor will always be a factor in your ability to deliver.

I’ll close with a quote from Alistair Cockburn – one of the founders of the Agile movement – related to process. ‘Process is indeed important. While a good process can’t assure delivery, and a good team can deliver despite an unwieldy process, a poor process can get in the way quite neatly’.

Leave a comment

Filed under Management, People, Project Management

10 *MORE* Ways to Manage Project Scope!


In my last post, I outlined “10 Ways to Manage Project Scope”. Those weren’t, of course, the only 10 ways to manage scope and just to substantiate this argument, here are 10 MORE ways to manage project scope. I hope you will find them helpful.

  1. Have a good customer. Ok, we’ll this might not be something completely within your control*, but if you’re fortunate enough to have a ‘good’ customer, this will go a far to help you manage scope on your project. How? By having the customer work with you and your team to do their part to help manage the scope of the project, rather than having them (at least seem like) they are working against you in this pursuit. Why would they do this? Because they understand that managing scope is a key tenant of project management/solution delivery that is very much interrelated with time, (schedule), cost (budget) and quality so it is in their best interest to do so. How would they know this? You will educate them on these sorts of things in the early stages of the project (if not in pre-project discussions). *So, maybe having a ‘good’ customer is in your control after all!
  2. Have a good support system. The only thing better than having a good customer is having a good support system. This could include having a team that supports the scope management process by doing a good job when collecting requirements and documenting assumptions to define the scope baseline that the scope will be verified against, and to understand the dangers of things like scope creep and gold plating. It could also include having the support of program managers, functional managers and PMOs that will support you in your efforts to manage scope – which could mean ‘pushing back’ with the customer when they want to add scope without being willing to accept adjustments to those interrelated items as noted above (time, cost, quality).
  3. Manage the requirements. In my last post I noted a few points related to capturing and agreeing upon some requirements as a best practice for managing scope, but that’s not where it stops. The management of the requirements is (or should be) a process that extends beyond the initial ‘requirements’ phase. While this process may differ across methodologies, having a process to ensure that requirements are updated as more details become known is vital to ensure that the team is working from a set of blueprints that reflect the current scope of the project. Further to this, the requirements management process should also ensure that the updated requirements are reviewed and signed off by all necessary parties – from the clients and stakeholders to the teams and individuals on the implementation team.
  4. Define success criteria. As part of the process to define the scope of the project, you should also define success criteria. Basically, define – in as detailed terms as you can – how you will know when you are done. Review this with team and the customer and ensure everyone agrees on it. Ideally, you will be able to define success criteria at not only the project level, but at the requirement level as well.
  5. Acknowledge milestones. Following on the point on definition of success criteria above, you can manage scope by acknowledging milestones. Acknowledging – along with the execution of other related processes and deliverables such as phase-end/toll-gate or deliverable (i.e. requirements document) reviews – can serve to ensure that any further effort related to a now complete phase will cease (assuming the scope for the phase has been verified). While most projects will have phase level milestones such as those noted above to transition from one phase (i.e. Planning) into another (i.e. Development), you can also build in mini-milestones along the way within the phases as a way to ensure that once a feature has been completed (based on defined success criteria) no further effort is put toward it.
  6. Don’t swap resources. While the ideal resourcing scenario is that you have team members that are dedicated (only allocated to one project) and are able to focus all of their time and energy toward your project (assuming the budget can support it) – working on multiple, concurrent projects is often the reality in the consulting world. As this much is understood, it’s not really a concern from a project management perspective. Where you do end up getting into trouble is when resources end up having to get swapped out, when other projects run late or other commitments take priority. While on paper, switching a developer/designer/’insert other role here’ with a similar skill set with another when a conflict arises seems easily done, doing so adds risk to the project in the form of additional ramp up that may be required, inadequate knowledge transfer and a lack of understanding of the project vision and objectives that would have been obtained having spent time taking part and contributing to earlier phases and deliverables.
  7. Watch the Burn. Over the course of the project, the project manager will be tracking the ‘burn rate’ on the project, to track how quickly the budget is being consumed and on which phases, work packages, tasks etc. While this relates more to cost management than scope management, if tracking has been set up so that you’re able to track at a work package or task level, keeping an eye on the burn rate can provide visibility into where additional scope may have been added where it shouldn’t have been. An example might be where a feature has already be completed yet there is still being time logged against it (perhaps by a resource that has been recently added).
  8. Educate the client on how to properly verify requirements. As part of your efforts to ensure the client is educated on the processes that will be used to plan and execute the project, it is important to ensure they understand the role they will be playing. One aspect of this role – and an important one if you want to ensure your project gets completed – is the expectations around how they will verify that the requirements have been met. Depending on the methodology, this may be an iterative process that happens several times over the course of the project, or it may happen at the end in a final UAT phase. Either way, it will be important that the client resources assigned to verifying the requirements, fully understand the requirements so that the time allocated to this phase(s) is used wisely. Further to this, they should understand the objectives of the requirements verification process which is, as the name would suggest, verify that the requirements have been met – not write new ones. That said, if an objective of having the client review and/or test the solution to verify the requirements is to look for ways to further enhance the solution, that is ok too, as long as it has been agreed upon as an objective and that you have a process in place to handle changes.
  9. Illustrate the impacts of scope changes. A major part of managing scope is having a process for managing change. It’s not about eliminating changes, since quite often at the beginning of a project, ‘you don’t know what you don’t know’ and as such changes are expected. That said, as a precursor to outlining the actual change control process, and the execution of it for every change that comes up, you should educate your customer on the concept of the ‘triple constraint’ (also referred to as the ‘iron triangle of project management’) (stay tuned for a future blog post on this) that explains the interconnected nature of scope, time, cost and quality. You can do this using tools and applications you are probably already using on your project such as MS Project or Excel, where you can illustrate (visually, in a status report, meeting or screen-share session) how the addition of a new feature or extra complexity in a previously scoped feature can push out the schedule or increase the budget beyond what might be is acceptable.
  10. Go Agile. In my earlier post, I noted that developing and validating iteratively was a great way to manage scope and build trust. Well if you think this is the way you want to go, why not try an Agile project?! While this is definitely easier said than done, since there are a lot of factors that need to be in place for an Agile project to be agreed to and to succeed (outlining all of these would certainly be ‘out of scope’ for this post), using an Agile methodology is certainly a good way to go when the requirements (that will drive the scope) of the project are largely unknown, due to the manner in which Agile handles the balance between requirements and development and responding to change.

So, there you go – 10 more ways to manage scope. Many of them relate closely to one another as well as to the original 10 strategies I posted [here], and of course not all of them will be possible to implement on every project. That said, hopefully they will give you an idea or two that you could use on your projects.

Leave a comment

Filed under Project Management

10 Ways to Manage Project Scope

Let’s talk about scope.


Not that kind of scope. Project scope! The “what’s in”, the “what’s out” and “how you are going to manage it” kind.

In my previous post, I outlined the 10 Project Management Knowledge areas, one of which was ‘Project Scope Management’, which the PMBoK (5th Edition) defines as,includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully”.

Well that sounds easy enough, right? So, what are these processes you speak of? They are:

  • Plan Scope Management – the process of creating a scope management plan that documents how the project scope will be defined, validated and controlled.
  • Collect Requirements – the process of determining, documenting, and managing stakeholder needs and requirements to meet project objectives.
  • Define Scope – the process of developing a detailed description of the project and product.
  • Create WBS (Work Breakdown Structure) – the process of sub-dividing project deliverables and project work into smaller, more manageable components.
  • Validate Scope – the process of formalizing acceptance of the completed project deliverables.
  • Control Scope – the process of monitoring the status of the project and product scope and managing changes to the baseline.

While all of the above processes are important when it comes to scope, the one that seems to get discussed the most in one form or another is the ‘control scope’ process. In fact, while ‘controlling scope’ is the context in which the conversation is often framed, the processes – as you’d expect – relate very closely to one another, so doing a good job in one area will often yield dividends further downstream. For example, if you do a good job of collecting requirements to establish what the scope actually is, this will help you when evaluating potential changes to the scope during the project, and when validating that the scope was met before you finish.

Also, still on the subject of ‘controlling scope’, depending on your chosen methodology, the process for collecting, documenting and managing the requirements that will largely drive your scope may not be following a traditional waterfall type of process where all requirements are known and documented prior to development. Understanding this, the notion of ‘controlling scope’ should be something that is balanced with having processes in place that will allow more detailed requirements to become clear as the project evolves, to ensure that the developed solution is addressing current and relevant requirements for your customer.

So while processes should always be tailored to the project, as no two are every completely alike, here are 10 ways that you can manage scope on your projects.

  1. Understand the business drivers, pain points and customer objectives for the project. Establish a shared vision. Getting everyone on the same page for what is it you’re building and why will be the foundation for all of the decisions you make on the project.
  2. Take the time to define and agree upon requirements. It’s always tempting to want to jump directly into building the solution, but take the time (regardless of your methodology) to agree on some requirements first.
  3. Establish a scope baseline. Acknowledge that changes may need to occur but agree to evaluate them against the agreed upon baseline.
  4. Ensure all key stakeholders, users and SMEs were involved in the requirements process. If any key stakeholders were left out, they could emerge later and add scope that could have impacts on the project.
  5. Ensure that due diligence was performed when defining scope and associated estimates and timelines. Make sure the team understands the complexities and effort for what you’re now on the hook for delivering. Ask questions. Document assumptions. Review with the client to get on the same page for whether you’re building a ‘Cadillac’ or a ‘Pinto’.
  6. Break the work into manageable pieces. If your WBS has a task that reads something like – ‘Feature 1-development: 80 hours’; this is a WAG, not a proper estimate, so you should take the time and energy to figure out how to decompose this work package into smaller tasks that can be properly estimated, otherwise accept that there is some risk in this ‘estimate’.
  7. Acknowledge that scope creep can kill a project (and beware of Gold Plating). Get agreement from the team from the client that sliding in even seemingly small changes has the potential to impact your project. This could include things that the client is asking you to add in, as well as little things that project team members might try and add in, in hopes to add some extra value (‘gold plating’). In the latter scenario, while these types of things are often well intended, it’s often the additional little item that will be the thing that results in an issue down the road.
  8. Develop and validate iteratively. While this may depend on your chosen methodology, showing progress will go far to allow the custom to validate parts of the solution along the way (thus reducing risk) and will also establish trust.
  9. Maintain a ‘wish list’. As change requests are raised and evaluated, maintain a ‘future enhancements’ list of items that weren’t able to be added to scope for the current release, as candidates for a subsequent release.
  10. Have a change control process. Last but certainly not least, establish a process for addressing changes. How to raise a change, how to evaluate/assess impact and who is responsible for approving or rejecting it. The change control process should allow time for the impact analysis itself, since even the process of performing the assessments (particularly if there are many changes being requested) can have impacts on the project, as team members need to shift focus from delivery of in scope features to assessment of changes.

1 Comment

Filed under Uncategorized

Here a BoK, There a BoK


Everywhere you turn these days there’s another group publishing their own BoK guide. A BoK, referring to a ‘Body of Knowledge’, of course. You’ve got your BABoK, the Business Analysis Body of Knowledge – a staple in the library of any self-respecting BA. There’s the SWEBok, the Software Engineering BoK for developers, architects and software practitioners; the QBok for the QA’ers; the UBoK for Usability professionals, and of course everyone’s favourite (Ok, maybe just my favourite), the Project Management Body of Knowledge, or PMBoK.

Before I proceed any further into this post I feel compelled to mention that if you work in any of the above noted areas and aren’t familiar with your respective BoK (or perhaps weren’t even aware there was such a thing) – don’t fret! It is entirely possible to be competent in your field without having your field’s BoK committed to memory!

I can’t speak for any of the aforementioned BoK guides other than the PMBoK, but the PMBoK – when outlining its purpose in its first few pages – is quick to note that is absolutely not a prescriptive ‘how to’ for managing projects. Rather, it is a culmination of ‘knowledge, processes, skills, tools and techniques’ that are ‘generally recognized’ as being ‘good practice’.

The PMBoK goes on to note what should be fairly obvious, that the concepts in the PMBoK guide are not intended to be uniformly applied and that the organizations and project teams delivering the projects are the ones responsible for determining what is appropriate for the individual projects being undertaken.

Whew! We’re not all going to be replaced by robots, mindlessly executing steps out of the PMBoK. That’s a relief!

As anyone who has ever worn the PM hat (whether it is was formally recognized as your role or not) knows, that while BoK guides and other theoretical tools can be handy (as paper-weights or door-stoppers, some might say), when looking for a consolidated view of industry best practices, quite often the real difference between a successful project and an unsuccessful project comes down to things like the intuition, judgment and experience of the team during the delivery of the project. Adaptation over adoption. Art vs. science.

That said, a little theory never hurt anyone either. Why not benefit from the collective knowledge of your peers and arm yourself with some knowledge and best practices that may just prove useful along the way?

With this dichotomy in mind, I thought I would create a few posts that will outline some of the core concepts from the PMBoK (and/or some other PM literature) in order to share some project management best practices. For the PMs in the house, most of this will be a refresher. For the non PMs out there, I definitely encourage you all to continue reading as well, as my hope is that doing so will give you a greater understanding and appreciation for all of the things bouncing around inside the head of your project managers!

As a starting point here is a quick overview Project Management Knowledge Areas and their PMBoK definitions. As I noted, in future posts I’ll do a deeper dive into some of them, weaving in some of my thoughts and experiences along the way.

  • Integration Management – includes the processes and activities needed to identify, define, combine, unify, and coordinate the various processes and project management activities within the Project Management Process Groups.
  • Scope Management – includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully.
  • Time Management – includes the processes required to manage the timely completion of the project.
  • Cost Management – includes the processes involved in planning, estimating, budgeting, financing, funding, managing, and controlling costs so that the project can be completed within the approved budget.
  • Quality Management – includes the processes and activities of the performing organization that determine quality policies, objectives, and responsibilities so that the project will satisfy the needs for which it was undertaken.
  • Human Resource Management – Project Human Resource Management includes the processes that organize, manage, and lead the project team.
  • Communication Management – includes the processes that are required to ensure timely and appropriate planning, collection, creation, distribution, storage, retrieval, management, control, monitoring, and the ultimate disposition of project information.
  • Risk Management – includes the processes of conducting risk management planning, identification, analysis, response planning, and controlling risk on a project.
  • Procurement Management – includes the processes necessary to purchase or acquire products, services, or results needed from outside the project team.
  • Stakeholder Management – includes the processes required to identify all people or organizations impacted by the project, analyzing stakeholder expectations and impact on the project, and developing appropriate management strategies for effectively engaging stakeholders in project decisions and execution.

Leave a comment

Filed under Uncategorized

An honour just to be nominated: BDC 2013

From the ‘its-quite-arguably-to-late-to-be-‘blogging’-about-this file’, here’s a cool story from a couple of years ago that I wanted to share.

Back in January of 2013, my company, T4G put on a conference called the ‘Big Data Congress’. It was the first of two such events that I’ve now been fortunate enough to have played a part in. I’ve written about the 2014 event, BDCII, here if you’re interested in checking out that post. T4G’s VP of Marketing, Cathy Simpson, the original ‘architect’ and primary event planner of both events posted about the inaugural event on her blog – here.

As these events were able to draw attendees into the multiple hundreds, with many attendees coming in from out of town, we were able to create a bit of economic activity for local restaurants, hotels etc – for a day two. As such, T4G was later nominated by Hospitality Saint John for an award at their year end awards gala in a ‘meetings and events’ category.

In addition to that nomination, each of the nominees were able to nominate an individual from their organization or organizing committee for their efforts in the planning and execution of the events. A couple days before the awards, T4G’s Cathy Simpson, who I reported into in my project/event management roll notified me that she had nominated me in this category and submitted the following story in doing so.

Check it out. It really hits the nail on the head in terms of all of the goings-on back when we were pulling this event together. Very cool indeed!


Hospitality Saint John – The Meeting and Events Award

Top Volunteer: Evan Sommerville, T4G Big Data Congress

We brought 500 people to the Port of Saint John, 20+ world class speakers and 20+ amazing sponsors to ensure the event was a success and yes, it was in January when the temperatures were frigid.

Planning a major conference is a bit like having a baby: there are a million little things to do before it arrives and there’s no turning back once it starts. No one knows this better than T4G’s Evan Sommerville.

Evan was the T4G project manager for T4G’s inaugural Big Data Congress, a one-day event held January 25th, 2013 that introduced a sold-out crowd of 500 to the power and potential of data science for the Maritimes. Evan is a project manager, which means he manages large, multi-team projects for many of our clients at T4G.

bdc 2013 planningEvan while very familiar with project management for software projects, he had never been an event project manager.  But he signed up without hesitation and did so very early into the planning.  So early in fact, we didn’t have a date yet. When we did set the date – January 24th, 2013 – Evan took a deep breath and still said yes. He already had that date in his head because it was days before his pregnant wife was due to deliver their second child.

It wasn’t an easy pregnancy and with a toddler at home, Evan balanced the needs of his family and his busy work schedule with the very large task of keeping track of all the speakers, sponsors, logistics, supplies and deadlines connected with T4G’s big event. That meant Evan worked through lunch, worked through the evenings after getting his 4 year old daughter to bed and often had to turn on the laptop on the weekend. This was an all hands on deck assignment.

Evan was the calm center in the midst of the flurry of planning and executing this major event. He kept track of all our notes, records and communications within the company and with all of the other stakeholders. A typical day for Evan would include taking notes during a planning meeting, calling around for quotes on linens or extra chairs, liaising between suppliers we retained to help with event production, ensuring speakers arrangements were taken care of and tracking to our budget.  He did it all with a smile, with a kind word to the people he worked with and an assurance that everything was going to get done.

While he did this, he would touch base with his wife throughout the day and as her pregnancy progressed and as the doctor appointments increased, Evan would quietly slip out to be with her. As we got closer to January 25th we joked around the office that it would be interesting to see what arrived first, the conference or the baby.  In those final 72 hours, none of us were sure, not even Evan.

In the end it was Big Data that arrived first, and Evan was there through it all, smiling – and prepared for anything. While his wife had her hospital stay supplies, Evan made us a BDC emergency kit, which contained all the information stored in his brain. Was he worried? Of course. Nervous? Certainly!  We all knew Evan might have to leave at a moment’s notice.We were all ready for that baby’s arrival, and when a happy and healthy baby boy did arrive just days later, it was an extra special celebration, because we knew how hard his dad had worked before his arrival.

The Big Data Congress was certainly a big effort. None of us had ever planned an event of this magnitude before and certainly not in the heart of the winter at 2 cruise ship terminals!  Evan provided all of us with the project management support we required and now he’s at it again.  Big Data Congress II is February 24th and 25th, 2014 in Saint John and Evan is back at it as the event project manager.  This time, no babies arriving are on the project plan.

Leave a comment

Filed under Events, Project Management

True Growth 2.0 ‘Civic Hackathon’

Back in June, I was involved with organizing a Hackathon, the 2nd in the ‘Inspiring Innovation through Hackathons’ series I’ve been leading with Enterprise Saint John. (See an earlier post for a recap of the first one here).

This Hackathon was focused around ‘Civic Hacking’, which can be defined as, “the process of collaboration with others to envision and create solutions using publicly-available data, code and technology relevant to their city or neighbourhood”.

The event was a ton of fun and a great success by all accounts. You can read all about it in a recap post that I created on the other blog I maintain here: and/or on the guest post I wrote for Enterprise Saint John’s True Growth SJ blog, here:

Adding an extra element of coolness to this event, or at least the post-event communications, was a video that one of my co-organizers put together with some footage he took during the event. Check it out!

1 Comment

Filed under General, Hackathons, Innovation, People