Sharpening the Saw

Recently I encountered a "perfect storm" of life events that resulted in a complete breakdown of my beliefs, confidence and motivation. I spent a couple of weeks trying to pinpoint the actual causes of this. I alternately assigned blame, tried to fake it, admitted failure, checked out by watching 1970's TV drama, commiserated with friends, sought advice and professional help.

Today I stumbled upon the answers by revisiting two old friends. I was introduced to one of these friends very early in my career. He helped me organise my work and private life, helping me understand what was important to me and where I should spend my time to make myself truly happy. He helped me set goals and gave me a little notebook to plan and track my goals and the tasks that would help me achieve them.

Then my friend introduced me to another friend. The second friend took my little goal-setting exercise to a new level. He asked me to look at the qualities that are important to me, and how I want people to describe me when I'm no longer around. My life was on track to be the journey I wanted.

Then I got a smart phone.

It was no longer cool to carry around a little notebook. I tucked away my little notebook in a drawer in my home office. I took it out for various life events in 2003, 2007 and 2011 (see a pattern?) where previously I had reviewed it annually. Today, as part of my trial and error approach, I located and read through my little FranklinCovey notebook.

Benjamin Franklin pioneered time management by setting himself the task of mastering 13 virtues for improving his productivity and therefore his chance of success. The Franklin Institute built on those virtues to create productivity planners for success-obsessed Americans in the 1980's.

Enter Stephen R. Covey of 7 Highly Successful Habits fame. When these two joined forces, well, that's when it got interesting. Stephen could put things in 20th century terms. He added important virtues like Leadership. I bit hard.

I'd forgotten what a marvelous tool this was! I spent the day in my study with my 1998 values, my 2007 goals, my 2011 bucket list and 6 pads of sticky notes. And I started sharpening the saw.

I started by affirming the 10 values I've had since 1998 (and probably before). I added the 26 things remaining from 50 item bucket list. Then I added items I'd recorded about how I wanted to Act, Feel and Think (AFT) and how I wanted to Be, what I wanted to Do and Have (BDH). By now I have wall of colourful sticky notes.

Next I looked at the Evaluation Questions. What has made me happy, satisfied and proud? Were these consistent with my values?

No. Guess what? In the past 15 years, I've added some values, and some are no longer important to me. My "perfect storm" of life changes brought clarity to this. Here's part of the sticky note scattergram attached to the wardrobe mirror.

I have been executing tasks to complete goals that I no longer want to achieve, because they no longer conform to my values. This conflict has caused me confusion, frustration, anxiety and ultimately, my failures.

Tomorrow I'll prioritise the values, and start setting some new goals. And I'll be checking out that Franklin iPhone app.

Adding Value

My MacBook has a sticky note displayed in the corner at all times as a constant reminder of successes and failures.

"What we must decide is how we can add value and not how valuable we are"
- Edgar Z Freidenberg

These days so many Project Managers learn Microsoft Project, hound resources to complete tasks, record issues in Excel, take a test and voila!  Look how valuable I am!  I am a Project Manager!

Let's say I come to work for you. Obviously you think I can contribute to the success of your business, and I think I can contribute as well. But if on my first day I walk in and think, "they will never do this without me" will I set the expectations for failure?

How do I achieve any value with that statement? When I sit at my desk on Day 1, I have not yet achieved anything! I have only promised to achieve and add value. So I start about the business of adding value.

Ok, so let's say I walk in on Day 180. I have a couple wins under my belt. You call me first when you have a new project to discuss. Now am I valuable? You bet. But you cannot put my value in the bank, or declare it to shareholders. You can tell the shareholders that you are backing me for a big project because of my previous record of adding value, but the shareholders will still judge us both based on the end value added by our project.


I add value by delivering. I can achieve it best with transparency; if I know the business strategy. Perhaps our company needs entry into a particular market and profits are not key. Maybe we must conform to government regulations and exact requirements and costs are critical. We might even take a smaller project in hopes of getting more work at the client. I will plan the project so that the most critical elements will get the most attention. I will tailor my day-to-day management based on the overall goals and objectives of the project, not by blindly following a canned methodology.

I also add value by bringing information to you, so that you can make informed decisions. "Did you see the article that the government has extended the deadline for compliance?" "It looks like our competitor just got that big contract we were hoping to get." "Companies X, Y and Z just announced products in our market."

Companies exist to make profit. And management must produce that profit. Seems simple, but not all workers care about this. As a business owner, I care. I always look for cost cutting measures in projects that won't affect quality, and ways for utilising staff better.  

Perhaps Dr Freidenberg wanted us to keep achieving: Set expectations and never rest on our laurels. I can rest when I'm dead. Until then, I'll keep adding value.

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.