Roles in SharePoint Projects (Response to OfficeOverEasy)

This blog-post inspired me write a bit about the project experience I have gained over the last couple of months/ years.

In theory and general I agree with the post that there are certain roles, the names need to have clear meanings, they don’t really in our world today and the architect is one of the most ambigious terms yet.

My take and additions on this topic are regarding

  • Architect Description
  • My Roles
  • Traditional Projects and Project Management
  • General Skills in the SharePoint Context
  • Developer Traits in the SharePoint Context

I will do this as a series of four posts. Today will be the first.

Architect Description and My Roles

In a former company of mine there was a trend or wish of management to have everyone categorized in a system of architects, where everyone was considered an architect and the different levels 1 through 10 were the experience level and mapped to a certain name with the suffix architect. The solution architect being the most senior combining business and technical knowledge. By the way: this would be me in about 10 years, but not if I had stayed with the company, because if your rating gets you a job and the rating is based on experience, how do you actually grow? That’s actually my biggest issue. Personal growth. How do companies today promote personal and professional growth?

Why do I want to be a solution architect and what do I mean by that?
Well, I like drawing images, I like infrastructure, but even more I love talking to the customer. I want to make sure that what I discuss with the customer will flow into the solution that will be delivered in the end.

I strongly believe in requirements engineering and test case design based on these requirements of the project, so there needs to be somebody who can define work packages (wbs – work breakdown structure) and guide the team from zero to hundred (start to end of project). The fact that I have been a developer, a test manager, a business analyst, a designer and a sub-project manager for different projects definitely contributes to this.

Jack-of-all-Trades is a good term, even though it is a bit negative, because people tend to say these guys know everything, but nothing well. That was quite true when I started working, my flexibility being my best trait, my zeal, confidence and will to succeed helped me to contribute in any role that was given and the fact that in SharePoint there are so few resources helped me get these opportunities in the first place.

The reason why I think I can contribute in these different roles is because I am quite curious how things work and I usually want to know everything I can wrap my brain around.

To get back to the architect topic, do I consider myself an architect? not really. I don’t design solutions every day, I do not do performance analyses, scalings, reviews as much as would be required. As officeovereasy says the architect would be the guy who has done this a thousand times and can tell you to do this or not. I am the guy you pick, when you can’t get anyone who has done this a thousand times, because my decisions are usually based on my experience with other programming languages and of course my academic background. I don’t know the solution, I can figure it out and it will probably be a good deal better than lots of other solutions, but I don’t have the confidence of 20 years and a thousand projects – and then of course I am way to modest to say I have all the answers. 😉


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: