Social Media: Personal or Professional?

Every year I have the opportunity to review and update my resume thanks to the nature of contracting.  It's time once again to dust of the curriculum vitae and hit the webosphere for the next big gig.

This year, it's a little different though, because I've found that recruiters and sometimes even employers are not only interested in my experience, but also in my activity. As a blogger and tweeter, I've decided to embrace this change and share with you a bit about my social media philosophy for separating Professional from Personal.

1. Assume that people (colleagues, friends, employers) will Google you.
What do you want those people to find? In my case, they generally find an award-winning chemical engineer at Yale. But once they find the correct Julie Zimmerman, they are likely to find this blog, my Linked in profile (currently top Google pick), my twitter and Facebook profiles. These internet postings are as powerful as my resume.

2. Designate a profile/ account as professional or personal in your social media.
I use Linked-in for my professional contacts and I keep all conversations professional, as if I were at work.  The same with Twitter and this blog.  Because both of these can be read by anyone at any time, I treat these as my own professional websites. No cheesy photos, pictures of food, comments about my state of mind or daily commute. I do occasionally tweet on personal subjects, but these are generally targeted as one-offs.

Facebook is my personal "expression" website, and though I would never allow anything on my Facebook that would discredit my professionalism, I would prefer not to have to explain an "out of context" photo or status.  My Facebook loyals would understand, but not someone who randomly lobbed in. I use the settings on Facebook to present  my professional image to anyone who would find my page via search. I make it a habit not to "friend" people on Facebook until we stop working together.

 3. Don't say anything on Social Media that you wouldn't say to someone's face.
There are just too many people with too much time on their hands.  You may end up on someone's FAIL page, or worse, one of your friends may be friends with your next potential boss. Tweeting is not the way to 15 minutes of fame.


4. Join only as many social media sites that you can maintain.
I have a friend who is a social media expert. I get invitations to join every new social media site out there.  Before joining, I always consider whether it will suit me to be a member.  Will I have time to update it?  Will it likely catch on in Australia? Does it duplicate something I already use? The answer is Yes, I have a Google+ account that I don't use.


Hopefully this year I'll be able to parlay my use of social media into my next career move, while still maintain a personal identity online.


How do you keep yours separate? Or do you? What issues has it caused?

10 Things Women in Technology Need to Know

I have just completed my 25th year in technology.  I've worked in almost every role: computer operator, data entry, developer, business analyst, project manager.  I entered when women were beginning to get numbers.  But there are so many things you have to learn the hard way.

After 25 years, I think I might be able to share a few. In no particular order:

1. Know your stuff.  Wanna play with the boys?  Make sure you are learning the same amount of detail they are! Read blogs, search the net, jump into that lunchtime conversation about Security in the cloud.
2. Get involved. Attend conferences, training, get certified, join user groups, write blogs.  Ask your boss to be involved in the new technology upgrade. Put a strategy in place for your career and what you want to do.
3. Volunteer, but not too often. Take on the new project, work a few extra hours. But make sure these will help your career! If you get the coffee, make sure everyone else takes their turn too.
4. Build relationships. Rarely does my next contract come from an advert.  IT is a small business. Use Linked-In and other social media. Knowing people in the business will help you throughout your career.  I've personally worked with over 20 CIOs and heads of consulting firms.
5. It's business, it's not personal. No one comes to work to ruin the work. If someone disagrees with you, it's because they have another goal or objective. They are not trying to ruin your life. If you want to succeed, find out what they are trying to achieve, and figure out how you can both get what you want.
6. Dress the part. Men have had a uniform for business for 100 years. It's called a suit. If they wear one, you can wear one. I like skirts, because I'm not a guy, or jackets over dresses. Think to yourself, would a guy be allowed to wear a similar piece of clothing to work here? Open shirt/ low-cut blouse? Open-toed shoes/ sandals? Shorts/ short (way above the knee) skirt?
7. Sometimes you have to be wrong to be right. Sometimes you will be the first one in the room with the correct answer. You want to speak up and say, "we should do it this way." But you can't. You have to lead the rest of the room to the idea. You will have far more success leading people to the right idea, if you are the one who has to take "credit" for the idea. Don't be upset about it, just do it.
8. Ride the wave. Technology is fickle. A good technology will be around for 20 years, but who wants to do the same thing for 20 years? If you are lucky enough to stumble onto the "right now" technology, make the most of it while it is popular.  Work your butt off for 2-3 years, and if you're lucky and smart, you can make a huge profit.
9. Find the need. If you are on a team of everyone with similar skills, find a skill that you have that they don't and exploit it. As a great organiser, I volunteered to enter the team's time into Microsoft Project.  This lead to me becoming a project manager.
10. They're colleagues, not girlfriends. Most importantly, don't treat your colleagues, especially your bosses like your besties. Don't gossip about the boss (he/she might be behind you) and never EVER show your alcohol capacity at a work function.  Sure, its okay to make a few besties from work, just don't make evident AT work.

The SharePoint Project

This week I attended the Australian SharePoint Conference at the Hilton Hotel in Sydney. I've decided this is the last year I will be an attendee. Next year, I plan on presenting.

I am currently managing my fourth "SharePoint project". This is somewhat of a misleading proposition. As a former application developer and business analyst, I have always tried to deliver based on business objectives. As a Project Manager, I need to understand why there is a "SharePoint Project."

What is a "SharePoint Project?" SharePoint is a platform. Thankfully, this is the main message out of the conference to those just beginning to dabble in the technology.  One session estimated, by a show of hands, that 40% of the room was on 2007, 40% on 2010 and the rest were "thinking about" going to SharePoint. This message is for that last 20%.

By the time I'm hired as the Project Manager, the platform has already been "installed." Infrastructure guys (and I love you) have found SharePoint on the Windows server and "turned it on". Now to tell someone how to use it!

Voila! The SharePoint project is born. Some sites get created; the webmaster thinks it would make a great intranet; the document/records lady notices you can tag stuff with metadata. The CIO throws a barely six-figure sum at the budget and asks the Infrastructure guys to do this in their spare time.

No wonder so many people hate SharePoint. It's treated like Infrastructure.

Paul Culmsee, in his Day2 keynote speech, noted that things like installing servers are simple. You plug it in and it works. It's basically the same every time. Sure you have to hook up dummaflobbers and whatsits, but servers are interchangeable for many purposes. And infrastructure guys are great at knowing all this.

Things like Exchange/ Outlook are little more complicated. You configure it based on requirements that are predictable. People want to get mail and send mail. The requirement and business objective is that the thing works. I don't have to ask anyone what "success" looks like.

SharePoint implementation, however, is complex or sometimes chaotic. The requirements are many. The Webmaster wants a good content management system; the Enterprise Architect wants good information architecture; the Records Manager needs a single source of truth. SharePoint has suddenly become the solution to everyone's problem.

But that's just it. It's a solution. You need a problem to solve. SharePoint can be configured and adapted to do just about anything, but you just don't know what that anything is yet. 

Mark Miller, the editor of EndUserSharePoint.com, is right in saying that business objectives should drive the use of the platform. If you're not careful, you could end up blow-drying your pizza, or microwaving your dog.

The platform needs to have a strategy, a reason to exist.  From the strategy, projects branded with the business purpose in mind can be launched. Each project - document management, intranet, business process workflow - should have its own business objectives and a determination made as to whether SharePoint is the right platform. 

Next year at the conference, I'd like to see less geeks and more business folks. Vendors should be inviting their contacts along to see how SharePoint can provide the platform for the solution.  I'd like to see Governance replaced by Strategy; Workflow Management replaced by Business Process Implementation; Site Branding replaced by Project Branding. Let's start using the term "SharePoint" in context as the middle-bit between Windows and the applications that run on it.

End Users can then be taught the Business Solution. And no one, other than the Infrastructure guys, should ever care that it's called SharePoint.

What would you like to learn about from a SharePoint conference?

When is AGILE not agile?

Late last year, Telstra, Australia's largest telecommunications company, introduced Agile development techniques to its IT software development project teams. The theory is that smaller, self-managed teams will create better software, quicker.

As a certified Project Manager with business analysis and development experience, I love the idea that deliverables can be parceled out to a small empowered team. Unfortunately, I have also been engaged to "rescue" or "re-discipline" some of these teams who have either failed to deliver a viable solution, or have exceeded the project budget without delivering. In my experience, many "Agile" IT shops are using it as an excuse to not have any governance or project management at all.

Still, I think there is an opportunity for Agile to create quick, sustainable and cost-effective solutions for business and IT. The Agile Manifesto was declared in 2001 by a group of technologists who were struggling to fight the tiered management bureaucracy to create effective solutions.

The first paragraph of the AGILE Manifesto Principles is:

"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."

A lot of emphasis is placed on "satisfy the customer" and "early and continuous delivery". But how do we define "valuable software?"

I pondered the Manifesto against my experience and came up with these Critical Success Factors for Agile Development.

CSF 1 - A succinct, defined problem

There is no doubt that a large problem such as "replace all legacy systems" cannot be Agile. Large problems require a big investment with commitment from a lot of people. Selecting small problems with tight solutions are key.  I've found that these work best for stand-alone web applications, or applications that collect or display data. Large implementations like ERPs and CRMs will never be agile, because you will never get a small enough base of knowledge, signoff, or commitment.

CSF 2 - A defined technical architecture

 "The best architectures, requirements, and designs emerge from self-organizing teams."

In this paragraph of the Manifesto, the term "architectures" must be defined. An application can only be efficiently managed if it conforms to the architecture investment of the organisation. For instance, if the shop builds all applications on Microsoft platforms, introducing a UNIX platform in the solution will not only delay the project, but increase on-going operational costs. Defined as "solution architecture," the team will create reusable code and objects that will make their lives easier as they add to the functionality of the software.

 

CSF 3 - Governance and measures

"The sponsors, developers, and users should be able to maintain a constant pace indefinitely." 

The Manifesto also ordains sponsors. This means that they will want progress reports. So before commissioning a team to solve the problem, we should determine how we will measure their success and report and approve their solution. Will we have an option to throw away the solution? How will we evaluate it before we spend additional money on additional functionality? How will we determine which functionality goes in which solution? At what point do we review the technical architecture and how information flows in the organisation?

"Working software is the primary measure of progress."

"Working software" should be defined as part of the problem definition. Is the solution designed for a single purpose or will the software be used for multiple problems?  How much functionality do we need before the software is considered "valuable?"

CSF 4 - Dedicated, empowered business users working with IT

 "Business people and developers must work together daily throughout the project"

Agile is not an IT methodology. It is a way for business people to solve their problem using the tool of technology. This requires a time investment of their most knowledgeable and trustworthy people. It means that only necessary staff should be on the team, and not political plants. If the "right" business people are not involved, then the software will not be valuable, because bureaucracy will again, takeover.
 

CSF 5 - Development and testing strategy and guidelines

"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."

Good developers are not always good designers or architects. Identifying constraints and boundaries for technical architecture and design gives teams a framework for their solution. Tools such as Microsoft Visual Studio allow developers rigour and flexibility. Enough of both should be included in the guidelines.

"Simplicity--the art of maximizing the amount of work not done--is essential."

The team should strive to build a solution that will allow for additional functionality and minimize re-work.  Testing guidelines should include testing by uninvolved team members. When business people get involved throughout, they start thinking "happy path" just like the developers. Define testing roles up front with the business. Consider user acceptance testing as training for the users.

"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly" 

Guidelines should be reviewed at the end of each scrum and recommendations made on what to change. The goal should always be to improve quality and speed, within budget and costs. The "amount of work not done" extends to future work that will not need to be done, or a conscious decision to include the work in a later release. The challenge for the team is to leave tidy code that is maintainable, and not just by the person who wrote it.

CSF 6 - Experienced IT and business users team members

"Continuous attention to technical excellence and good design enhances agility."

Inexperienced team members cannot make informed decisions about excellence and good design. They will likely take the quick and happy path to solution development, creating solutions that are difficult to maintain, enhance and integrate with other solutions. Team members should also be aware of good business analysis and project management principles, especially budget and time requirements.

Team members must be multi-disciplined and collaborative. Egos should be kept in check, with the solution a priority.

There's no guarantee that your Agile project will be a success, but if these are defined up front for all Agile project, I'm backing that you will have a better chance of success.

Project Manager Time Quadrants

In 1995 I managed my first Information Technology project. It was for an organisation that did not have formal methodology experience, but they were pleased that I did.  It was very much a 1 to 1 relationship between me, Project Manager/ Business Analyst and the Project Sponsor/ Subject Matter Expert.  My focus was on capturing requirements and feeding them back to the developers, managed by another line manager. I spent nearly all of my time managing the relationship with the key stakeholder, and delivering the project; almost none managing the relationship with the delivery team and administering the project.

By contrast, in my last project, I had 15 high-profile stakeholders and subject matter experts. My delivery team was spread across 3 divisions with 3 different managers. I was considered one of the subject matter experts in the technology, and this organisation has a large and complex project reporting structure.

How is one project manager meant to fulfil all the roles in the Project Management life cycle?

Generally, there are two things a project manager spends time on: Relationship Management and Delivery Management.

Relationship Management focuses on who you spend your time with to get the results you have promised for the project. This can be Stakeholder-focused such as the Project Sponsor, Steering Committee or End users or on your project team who are providing the deliverables.

Delivery Management focuses on how much time you spend providing feedback on progress. Administrative focus is heavily-based on methods, formulas, EPMs and reports. Delivery focus is based on showing frequent and accurate results, such as prototypes and releases.


If we plot these on a grid it looks like this:

So let's say you spend 100% of your time updating Gantt charts, checking on task status, writing reports and updating budget spreadsheets. We call this the Project Administration Quadrant. More time is spent on reporting and communicating with the team.

The opposite extreme is the Stakeholder Manager Quadrant. The Project Sponsor or Owner has hired you, the Project Manager to turn a mish-mash of opinions into a functioning system, application or network.  This is the hardest of the roles because it requires up to 100% of your time setting and managing expectations of the stakeholders who want (or don't want) the project to succeed, whilst focusing on the delivery of their objectives. You have little time with the team, and little time to report on progress. If the Stakeholders are high-profile, a Project Director might be brought in to manage the individual project managers. This is the Project Manager role I prefer, but with a Project Director in place (or with me as the Project Director).

If your time is spent managing the delivery team and the deliverables, you fall into the Team Leader Quadrant.  These are usually straight forward requirements with a small number of stakeholders.


Lastly, the Program Management Quadrant requires a lot of administrative time and management of stakeholders. Program Managers rarely interact with the delivery teams or the act of delivery unless problems arise.

So in which Quadrant does your current project reside? In the next blog, I'll show you how to use this quadrant for your project planning.

Forget Sponsors, Champions Rule!

The Project Management bandwagon has made Project Steering committees "fashionable". Despite a Project Manager's best intentions, a seat on the committee can be politically desirable, resulting in too many stakeholders, too many agendas and the nomination of a sponsor so high up in the ranks that he/she does not have the time to dedicate to the project objectives.

Enter the Project Champion.

This is a person on the steering committee who is respected by all members, especially the project sponsor. But most importantly, the strategic agenda of the Champion depends on the objectives of the project outcomes.

In other words, your project is one of the most important to them.

With a Champion in place, you are able to have almost daily feedback from the agenda makers. Your project has a voice at every meeting of the Champion's peers and higher-ups.

Why is this important? Word of mouth is a powerful thing. If your project is important enough to be discussed in meetings you didn't attend, then everyone starts believing it is important for the organisation.

Requests for resources are magically granted! Training receives full attendance! Another bandwagon is launched!

So how do you find the Champion in the politically charged environment? Ask questions, offer to do research, volunteer information. A little work outside of the straight-line project management will uncover the person who is most likely to manage upward and outward, so you can concentrate on delivery.

Risk management has killed project delivery

How many different points of risk management does it take before a project is properly risk managed?

I recently wanted to acquire expert services for a project. I have completed similar projects before and these projects take about 3 months from the time you get requirements, and with full cooperation of the necessary teams. These I had already established.

Despite the fact that I am a veteran, certified Project Management Professional (in two disciplines) I was forced to undergo the rigid "risk management" processes of the procurement department under the guise that it was "required."

Six weeks later, (now 5 and half months after my project start), the evaluation team selected a vendor through the rigourous process and I was prepared to make an agreement. Since this vendor had little experience with the organisation, I mitigated the risk by awarding the work in two sections: three weeks, and then the remainder to be re-quoted at the end of the first period.

This vendor has a head agreement, so a contract with terms and conditions is already in place. With a firm agreement on what was to be delivered in the first three weeks, I sent the work order back to the vendor, expecting a one day turnaround.

The risk management team from the vendor clearly re-vamped the entire work order, adding resources that I did not want, and deleting resources that I required.

They mistakenly thought that volume was a replacement for quality.

In the end, I stopped negotiations with the vendor (by this time, half of the three weeks had passed) and signed up another vendor who could provide me with the quality resource I needed right away.

Sadly, had I been able to trust my own risk managment experience, I would have been able to engage the second vendor two and a half months ago, and the project would be well underway.

These days, risk management is in every aspect of a project. Or rather risk avoidance, which is only one of the risk strategies.

Should we do the project? If so, what things could go wrong if we undertake it? What if an earthquake hits the east coast of Australia?

News flash: If an earthquake hits Sydney, there's a much bigger problem than whether or not a $300K website is up!

Ok you want a vendor? Well you have to manage the risk that the vendor won't deliver. And guess what? The vendor is trying to manage the fact that you, the project manager, don't know what you are doing and will not give the vendor what they need in order to deliver.

The blame game starts before there is even an agreement to do work.

Wasn't the purpose of getting certified to prove that I was capable of making these types of decisions? How can I be a true professional when I am constantly being second-guessed by over-cautious lawyers?

Ok, I agree it may be necessary sometimes. Ten million dollar projects are often executed and fail to deliver their required results. But maybe it's not anyone's fault. Maybe it's just that the market or the business or the rules changed in the 5 years it took to execute the project. You can mitigate every risk and still not win.

I know one thing, with a 3 month delay on a 3 month project, this is how I lose credibility for delivering.

I guess that is a risk I should have mitigated instead of accepted.

Question: How do you mitigate the risk of being risk over-managed?