Monthly Archives: June 2012

How to Market Better: 3 Key Tips for More Successful Projects and Products

  By Hala | June 28, 2012 - 11:56 pm | Business Success, Entrepreneurship, Leadership, Project Management
1 Comment

Remember at the end of this post, where we talked a little bit about marketing, and I promised to write a post with some key marketing tips? Well here you go!

 

If you’re a project manager, you may be wondering why a post about marketing would have any significance to you.

 

Really? REALLY? You’re seriously wondering that?

Didn’t you read this post about the 5 Ways a Project Manager is Like an Entrepreneur?

(Shout out to the inspiring and awesome Robert Kelly of Kelly’s Contemplation, who is also the co-founder of #PMChat – the coolest project management tweet chat there is!)

 

Ok, so back to marketing, and how SMART marketing can make your project and product successful.

Let me give you a little tip.

Successful marketing boils down to one thing: Understanding your customer.

 

If project managers can get into the head of the end-customer and understand their need, their pain, their desires, then guess who has the upper hand when requirements need to be prioritized? Or when a feature compromise needs to be made?
(Better yet is if project managers can get the end-customer to TELL them what their need, their pain, and their desires are.)

Yep, youuuu guessed it! The mighty project manager!

 

Here are 3 key tips to help you market better, regardless of the medium you decide to use as your main marketing platform (you will need many, by the way).

By focusing on these 3 things and keeping them in mind, you can create a marketing strategy that brings your target customers running to you!

 

1- Define your target market. (Be specific!)

Seriously. You don’t want to be marketing your product to everyone who has a pulse. Not even to everyone who uses a computer. Not even to everyone who needs to manage their finances.

 

Ask yourself this: Can you imagine a specific product for those target markets?

 

A better target market would be, for example, people who need to manage their finances on the go, need to access their information from a mobile device, and are looking for ways to save money on their monthly expenses.

 

NOW can you imagine a specific product for the above target market? I see a mobile personal financial management application that can analyze recurring expenses and make suggestions for how to save money.

(Ok, so maybe you can come up with a better target market than the one I came up with, but you get the point.)

 

2- Figure out where your target market spends their time, and market to them there

Is your target market on Twitter all day long? Are they reading blogs? Are they on Facebook? Are they on the playground?
Then that’s where you need to be, too.

 

3- Speak your target market’s language

Simply put: Don’t use complicated, industry-specific jargon and terminology if that’s not how your target market talks.

(On the other hand, if that is how your target market talks, then by all means, go ahead and use those big words and complex sentences.)

 

As always, I’d love to know what you think! Are any of these marketing tips something you can benefit from in your role? Do you have any other killer marketing tips we can benefit from?

3 Reasons Why Your Project or Product isn’t Making You Rich

  By Hala | June 27, 2012 - 12:34 pm | Business Success, Entrepreneurship, Process, Project Management
5 Comments
features_value

A few weeks ago, I wrote about 3 Reasons Why You’re Not Releasing Your Money-Maker Project (click the link to read the post), and presented the following:

  1. Chaos (or Lack of framework)
  2. Authority Ambiguity (a.k.a Too much access to the product development team)
  3. Perfectionism

 

By now, you’ve figured out what you need to do to fix these 3 things, and you’re well on your way to releasing your product in appropriately-sized iterations of business value, RIGHT?!

I thought so. Because you are a genius. (Yes you are!)

 

So now you’re releasing away, happy as a clam, until one morning you wake up, look at your company’s finances, and see the following questions flash in front of your eyes:

 

WHERE’S THE $$$$? The Cash? The Profits?

In other words, why isn’t your product making the money it was supposed to be making?

 

Here are 3 reasons why your product/project isn’t making you rich:

1) Too many features

Have you heard of the 80-20, or Pareto rule?

In a nutshell, the 80-20 rule states that for many events, about 80% of the effects come from 20% of the causes.

Translated into the product development or software products world:

20% of product features provide 80% of the value (to the user)

 

In other words, you should be focusing 80% of your time and effort on that magical 20% of features that provide the most value to your target users!

Most of us, however, love to create. It’s easy to get sucked into a mode of adding more! more! more! features and thinking we’re providing more value to users, when instead, we’re making our products harder to use.

So, instead of thinking bigger is better, try to take a step back, and figure out  how you can simplify.

Can you identify that magical 20% of features, then focus the majority of your efforts on them? Maybe cut out a feature or 2 or 10?

 

This leads us nicely into the next point, which is..

2) Not involving your target users/customers

How can you figure out what your magical 20% of features are if you haven’t involved your target users/customers in the design and review of your product?

A lot of us think we understand our target user really, really well.

Maybe we even think we are our own target user.
(Tip: Consider that a conflict of interest, and find someone else to represent your target user!)

I invite you to conduct an experiment, which may shock and awe you, but will also show you how far you’ve gone down Assumptions Road when thinking of your target user.

Experiment:

  • Gather a few people you consider target users/customers
  • Provide your selected target users with a version of your product that they can test/play with
  • Give them only MINIMAL instructions – just enough to get your product up and running – and then sit back and observe
  • Watch how your target user interacts with your product, and TAKE NOTES!
  • Do your best not to get involved
  • Questions to think about:
    • Did your users have issues just getting your product to launch?
    • Did your users have issues figuring out how to use a certain feature?
    • Were your users confused about the reason for having a certain feature?
    • Did your users use any features differently than how you had planned them to be used?

Hopefully, by conducting the above experiment, you will realize how important it is to involve your target user or customer:

  • At the beginning of your project
  • Throughout your product’s development lifecycle

 

3) Marketing Done Wrong

Oh, Marketing. You are so elusive, and tricky, and fickle.

One day you want us to be on TV ads and in newspapers, and the next you are shouting at us to create banner ads and spam-email everyone who has a pulse.

Then you come up with this whole social media thing, and we’re all just totally. confused.

 

There are many approaches you can take when marketing your products, and there are many other people (that are a lot smarter than I am about marketing) that can tell you how to do it right.

Still, I plan on writing a post that talks a little bit about some key marketing tips that I think are constants, no matter your medium.

 

What do you think? Which of the above 3 reasons can you focus on to start making more profitable products?

The Power and Beauty of Community

  By Hala | June 25, 2012 - 12:46 am | Agility, Community, People, Project Management
Leave a comment

This past Friday, I had the opportunity and privilege to volunteer at the Agile Roots conference in Salt Lake City, Utah.

By volunteering, I was given access to the conference organizers, speakers, and events, and was beyond excited to be able to be a part of a conferencethat brought together some of the best and the brightest Agile minds out there.

 

I also recently volunteered for and spoke at the PMI – Norther Utah Chapter’s annual Professional Development Day.

The PDD is an event where project managers (whether just beginning or seasoned experts) come together to learn, share experiences, and improve as a community.

Again, I was excited and grateful to be amongst thought leaders who were changing the face of project management, and honored to be given the opportunity to speak.


(To access the slides from my presentation, fill in your name and e-mail address in the sidebar where it says “Project awesomeness, delivered to you!”, and I will send you a link!)

 

Needless to say, the last couple of months have been a flurry of activity and have been filled with opportunities to meet some extraordinary people.

However, I feel the need to make a confession.
Just one year ago, even though I knew I loved project management, Agility, and helping people achieve their goals, I was stuck.
I thought I was limited to meeting the demands of my daily routine, and that I would never be able to meet or work with people who shared my passions.

How wrong I was!
Just as anything else in life, I learned over the past year that to get where you want to be in life, and to truly make a difference, you have to put yourself out there.

You have to position yourself so that you are in the middle of where the learning, growth, exchange of information, and opportunities exist.

 

But before taking even that first step of putting yourself in the path of opportunity, you must commit to one key idea that will make or break your pursuit of a life doing what you love:

Give with abundance and serve others without the expectation of something in return.

 

Only then will you realize the power of true connection with other people.

Creating bonds that last, relationships that are genuine, and serving others with your unique talents and unique gifts will open doors you never thought were available to you.

Nowadays, whether through my blog, through social media, or through building face-to-face relationships with people who are doing what I love to do, my first goal is to provide some benefit to someone.

It takes almost zero time for that kind of mindset to reciprocate in your life and for you to realize the power and beauty of having a community of like-minded people available to you.

I look forward to another year of growth, connections, and more of doing what I love, hopefully with a bunch of you on my side!

 

What can you do to “get yourself out there” and start connecting to a community? Can you volunteer, or get involved in a local meetup group? Can you create a group if one doesn’t exist? Be creative!

Back to Basics: Project Management Tool Burnout

  By Hala | June 20, 2012 - 4:08 pm | Agility, Process, Project Management
Leave a comment

I love tools.

 

After all, I’m a Project Manager, and tools in my toolbox are what keep my [project] world go ’round.

 

These days, there is a plethora of project management and productivity management tools out there.
(And no, you don’t need to look ‘there is a plethora’ up – ‘plethora’ is a singular noun. Dictionary.com told me.)

 

Tools for tracking progress, scheduling, calculating and reporting statistics, project forecasting, task management, note-taking, collaboration, issue tracking, issue reporting, time tracking (yuck, ok this is one tool I don’t love), etc.

 

Like I said, many of these tools are amazing and can really facilitate results.

(Note: If you are looking for reviews of tools, especially Agile tools, go to Agile Scout – Peter has some of the most comprehensive and useful reviews out there!)

 

However, on some days, I find myself needing to reduce the noise of seeing one more screen, and one more interface. Those are the days when I have project and productivity tool burnout.

 

On those days, I go back to basics.

On those days, I pull out a pen and paper, and exercise my writing muscles.

 

Sometimes, writing words down on a piece of paper can have the transformational effect of making them more likely to turn into reality.

 

What about you? Do you love your tools? Do you enjoy writing things down sometimes?

 

 

Where in the Scrum Does a Project Manager Go? Part II

  By Hala | June 20, 2012 - 12:15 am | Agility, Paradigm, People, Process, Scrum
5 Comments
Scrum Masters & Product Owners - Characteristics

In my last post, Where in the Scrum Does a Project Manager Go? Part I, I talked about my experience as a Program Manager in a group that was making the transition from Waterfall to Scrum.

In this second installment, I’ll talk about a few other aspects of the transition we experienced, and how we navigated away from the shores of the Waterfall and onto solid, Scrum-y ground. (Ok, ok, I’ll stop with all the land and water references now.)

Today, we’ll be exploring:

  • Product Owner or Scrum Master?
  • The Role of the Quality Department

 

Product Owner or Scrum Master?

As Scrum teams were being formed and roles being determined, some Project and Program Managers were placed in either Scrum Master or Product Owner roles.

Note: A few Program Managers stayed in their Program Manager role – usually in cases where there was a large program that required cross-functional team coordination and management.

 

But what determined which role people took on?

Although I wasn’t part of the decision-making process, I noticed characteristics that I believe contributed to people being selected for each of the Product Owner and Scrum Master roles.

These qualities are also what I believe contributed to the success of people in these roles:

 

Scrum Masters & Product Owners - Characteristics

 

The Role of the Quality Department

Back in Waterfall world, the Quality Department was separate and independent from the rest of the team.

Although the Quality Department was involved throughout the life of the project, for the most part, testing occurred at the end of development.
I.e. at the end of a project/release cycle, code would be packaged up into a release, and sent over the wall to the Quality and Test Department to test, analyze, and report results back.

 

The problem with this model was that issues were being found close to the target release date.

 

Testing at the end

=

SCRAMBLE!

PANIC!                                                                 RED FLAGS!

warning signSOFTWARE PATCHES!                                  WORKAROUNDS!

This translated to:

Lower quality, Higher stress, and more missed or severely stretched out deadlines.

 

At the time of the transition to Scrum, the Quality Department continued to operate as a separate department within the organization.

Even with the Quality Department being separate, QA Engineers were integrated into Scrum teams, and there was a general sense of One Team One Goal.

Over time, things continued to improve.

Quality Engineers got more comfortable with their position and role on the Scrum team, and took the lead in quality risk analysis, defining acceptance criteria, and ended up going way above and beyond the role of “tester”.
One by-product of working on Scrum teams that has influenced me to this day is:
Allowing people to self-manage within a cross-functional team can provide powerful fuel for innovation, purpose, and commitment.

Stay tuned for the last (and more controversial) post in this series, where we’ll explore the concept of “By the book”.

Shameless plug: Subscribe in the sidebar and be the first to know when new content and freebies appear on the site! Aww yeah lovin’ me some pmlove. :)

 

Where in the Scrum does a Project Manager go? Part I

  By Hala | June 17, 2012 - 10:53 pm | Agility, Paradigm, People, Process, Project Management, Scrum
4 Comments

A few years ago, there was a totally rad Program Manager who worked with a totally rad-er R&D team on big, cross-functional programs.

 

This Program Manager was rockin’ at her job (obviously), and enjoying the fruits of her diligence in learning and applying her department’s Waterfall of a process.

 

She got so comfortable with the process that she could sometimes swim in the Waterfall with her eyes closed.

 

Still, her (and other PMs’ in the department) programs and projects kept pushing right up against schedules, sometimes causing panic in big corner offices.

 

Then, someone from one of the big corner offices made the decision to allow the Waterfall to dry up, and to give Agility a go.

Scrum trainers were immediately brought in, books were read, and rules were set. (Sound familiar? More about that later).

 

The PMO was abuzz, and lit with the fire of the one question that was on everyone’s mind:
In this new world of Scrum, where do all the Project and Program Managers go?

 

As everyone learned very quickly, there are 3 roles in Scrum: Product Owner, Scrum Master, and Scrum Team.

 

No mention of Project Managers.
None.
(There’s a glimmer of hope when you start reading “Pro..”, then your face falls as your brain processes the rest of it: “..duct Owner”.)

In this new world of Scrum, Project and Program Managers needed a home, and with time, everyone concluded that there were three options:

1) Project/Program Managers could become Scrum Masters
2) Project/Program Managers could become Product Owners
3) Program Managers could keep their job as Program Managers, and learn to adapt processes and practices to work effectively between the Scrum team and the stakeholders

The end-result was a mix of all three:

1) Some R&D Project managers and some R&D team leads became Scrum Masters
2) Other R&D Project managers and some Program Managers became Product Owners
3) Some Program Managers remained Program Managers, but worked with stakeholders, Scrum Masters, Product Owners, and Scrum teams in a new way

It was an interesting and exciting time, with many highs and lows.

In the end, though, I learned a big lesson that has stuck with me throughout the years:

Job security is created via the possession of unique, solid skills and a passion for what one does, not via a job title.

 

It was the people who had a dedication to their work, along with a strong and differentiated skill set that were found a home in this new environment.

 

It’s not to say that people who possess these things will never lose a job or be at risk of losing a job. But those people will move on, and they will find a home that appreciates their talents.

In the next installment, I’ll talk about what characteristics and skills I saw as facilitating the move to either Scrum Master or Product Owner for Project and Program Managers.

Effective Meetings: Follow-On and the Steve Jobs Article

  By Hala | June 13, 2012 - 1:50 pm | Communication, People, Process, Project Management
Leave a comment

In light of my last post (My One Secret Tip to Running an Effective Meeting), and taking into consideration all the Twitter activity I’ve seen on the FastCompany article titled: Meetings are a Skill You Can Master, and Steve Jobs Taught Me How, written by the brilliant Ken Segall, I felt the need to write this follow-up post.

 

I’ve seen first-hand (haven’t we all?) how focus gets diluted when meetings include everyone under the sun that might have an opinion about your project.

 

It starts innocently, with a “Hey, I know this person who might be interested in this meeting”, and ends up with your meeting invite being forwarded to 20 additional people, some of whom you might not even know.

 

Next thing you know, the conversation has taken on a life of its own, and people aren’t even thinking about your original meeting objective anymore.

Worse yet, you may have just wasted a whole hour (or more) of your and other people’s time.

 

These days, that’s just not acceptable.

To address this, Ken writes about the “small-group” approach to meetings (and teams!). In his article, he talks about the concept of keeping your meetings “small”, and enforcing the “small-group” approach.

 

He illustrates this with the example of Steve Jobs ejecting a meeting participant from the room because there was no need for this person to be in the room.

 

On the surface, it might seem like Ken is advocating for Steve Jobs’ approach to “ejecting” unnecessary players from meetings.

Personally, though, I think Ken is saying a lot more. Ken’s post is really about leadership and achieving great results, through finding the right way to keep your meetings (and teams) focused and effective.

While I don’t advocate Jobs’ approach to “ejecting” someone from a meeting, there is A LOT about the small-group approach that I agree with.

 

To summarize: Small groups of skilled pople are able to be more focused on the mission of achieving great results.

Ken makes a point in his article that I think is key for people to focus on and really think about regarding how to approach the small-group idea:

“One must be judicious and realistic about applying the small-group principle. Simply making groups smaller will obviously not solve all problems, and “small” is a relative term. Only you know your business and the nature of your projects, so only you can draw the line between too few people and too many. You need to be the enforcer and be prepared to hit the process with the Simple Stick when the group is threatened with unnecessary expansion.”

I.e.:
Analyze your project, organization, and team’s needs to come up with the right definition of “small-group” that works for you (as a group).

 

My Key Takeaways:

  • Not all businesses/companies have (or should have!) the same culture.
    Just like people are different, so are companies. What works in one will not fly in another.
  • As a project manager, you have the opportunity to lead people by example and influence. You can guide the way towards enforcing the small group concept in a way that stands out and is excellent, but without losing credibility with the people you need on your side.
  • Sometimes, ya just need to have a meeting agenda.
    In his article, Ken mentions typically not having a meeting agenda when meeting with Steve Jobs, which probably fostered the flow of ideas and worked well with the way that small group functioned.However, in some cases, especially in the scenario where you have different people from different backgrounds and in different locations, having no meeting agenda will probably cause either chaos or minimal participation.

What do you think? Are you a small-group enforcer?

My One Secret Tip to Running an Effective Meeting

  By Hala | June 12, 2012 - 2:34 pm | Communication, Process, Project Management
1 Comment

Meetings/conference calls are my playground.

I get to be alternately super-loud and talkative, then super-observant and quiet all in the span of a few minutes to an hour.

But running meetings effectively (especially virtual meetings where most people are on the phone and not right there in front of you) is a skill that must be learned.

There are many tips that can help you run a successful meeting/ conference call, but for today, I wanted to share the one meeting tip that can turn around your meetings today and make you feel so much more in control.

Meeting/ conference call secret weapon:

Spend 10 – 15 minutes before a meeting preparing and writing down your meeting agenda in your meeting notes template, and use that agenda to guide the conversation during the meeting.

Simple! Easy! Right?

Wait, you already knew about creating an agenda before your meetings?

So did I.

Then I stopped using them (sometimes) because I thought I was “too busy”, and found myself scrambling to organize my thoughts 5 minutes before meetings, pulling topics out of thin air during the call, and ending up feeling like this:

“That SHOULD have gone better than it did.”

So, if you’ve ever maybe lost sight of the importance of writing out your agenda, here is a handy list of benefits for you:

  1. Focus
    Creating an agenda forces you to think through and focus on the topics you need to discuss with your team
  2. Prioritization
    By writing your agenda down (ok, typing it), you visually see the topics and can rearrange them by priority
  3. Efficiency
    By writing out your agenda ahead of time (and possibly filling in some of the details if you have information to share), you can save time during the meeting and have some of your notes pre-written (vs. trying to write everything down during the meeting)
  4. Collaboration
    If you have your agenda prepared ahead of your meeting, you can send it to your team members and ask for feedback.
    Team members are a great resource for determining what topics should be covered and whether you should re-shuffle the order of topic discussions.
  5. Effectiveness
    By sharing your meeting plan with your team, people have an opportunity to prepare ahead of time, and to be ready to discuss certain points.
    Also: No surprises. Always good when you need to engage a number of different people in discussions that are key to your project’s success!

Oops, gotta run to a meeting…

3 Reasons Why You’re Not Releasing That Money-Maker Project

  By Hala | June 11, 2012 - 1:53 pm | Business Success, Entrepreneurship, Project Management
3 Comments

Are you an entrepreneur, investor, team member, or executive of a small business/ startup who is feeling the pain of being stuck in perpetual ‘almost-ready-to-release-but-not-quite-there-yet’ mode?

A few years ago, I was.

I learned (the hard way), what was standing in the way of us being able to release, to launch, to get out there and hustle!

I want to save you from having to learn the hard way, by sharing my lessons learned.


If you want to learn what things are holding you and your team back from releasing that money-maker project, read on!

Three main reasons you may be having trouble releasing your product and gettin’ your profits on:

1) Chaos (i.e. Lack of framework)

2) Authority Ambiguity (a.k.a Too much access to the product development team)

3) Perfectionism

 

Let’s break these down:

1) Chaos – or Lack of product development framework

I’m all for flexibility.

In fact, flexibility was one of the key things I highlighted in a recent presentation to my local PMI (Project Management Institute) chapter on how to achieve project success.

But before you can be flexible with your process, you need to have a solid working knowledge of it.

(To illustrate this, check out slide number 14 from my People over Process presentation. The one with the cool aikido move where one guy flips another guy in the air!
Note: For access to the presentation, use the sign up form in the sidebar!)

In the presentation, I introduced the concept of Shu-Ha-Ri, which you can read more about in Martin Fowler’s blog, as well as on Alistair Cockburn’s site.

Basically, there are 3 levels of learning/practice, with Shu being the very first, most basic level, and Ri being the highest.

Once you reach the Ri level of mastering a certain skill, you are able to effectively modify or adapt it while still achieving your desired result.

In a newly formed organization/team, there is a need for a certain structure and/or framework. This structure can be ultra-lightweight while still providing the roadmap to follow for building and releasing products/projects, and ultimately, MAKING $$$$.

Solution 1: Ensure you have someone in your organization who has experience and knowledge in different product development processes.

This person should have enough experience to be able to modify and adapt processes as needed for the organization and team, leading to successful release!

 

2) Authority Ambiguity (a.k.a Too much access to the product development team)

Open-door office policies and flat company structures are great.

They foster open communications, leadership at every level (because people don’t feel “managed” by other people in closed-off offices), and transparency.

However, too much manager and executive access to the product or software development team can become a problem for a couple of reasons:

  1. Conflicting directives: Who does the team listen to? The product development manager, or the charismatic CEO who, inspired by a great conversation or article, may drop by the product development team and throw out a “We should do THIS!”? (Leaving the team to wonder: Does that mean we’re supposed to BUILD that feature? Or was it just an idea?)
  2. Distraction: It’s tempting in a startup environment to want to question what’s happening and what the progress is at virtually every minute of the day, but this quickly becomes an impediment for the team.

Solution 2: Put an effective project leader in the right place at the right time, and allow her to be the buffer (when needed) between the team and management.

This creates more focus, productivity, and clarity of direction for the team. (And gets that product out the door!)

3) Perfectionism

You’ve hired the best of the best.

The people that know more about what they’re doing than you ever will. You know that combined, their potential is limitless.

But together, you’re still struggling.

That’s because the best of the best do not accept anything less than perfection (or close to it!). They know that if they spend 2 more hours, 2 more days, 2 more weeks on that feature, they can get it just right.

The secret here is realizing: You don’t have to be perfect. At a certain point, the returns you get from perfecting something are not worth the effort required.

Someone needs to help guide the team towards accepting what’s “good enough”. This can happen at 3 different stages of the project or product development:

  • When defining the product features (i.e. up-front)
  • When writing test cases and acceptance criteria for the features
  • When reviewing test and/or demo results

 

Solution 3: Empower your project leader to challenge the definition of “good enough”.

Make sure to evaluate the benefits gained from adding features and functionality vs. the cost of doing so.

Your turn! Share with us:
What are your pain points as a team, startup, or small business? Which of the above solutions do you think would make the biggest impact on your project team?

 

Manageable Mondays: No More Information Goose-Chasing

  By Hala | June 11, 2012 - 12:15 am | Communication, Project Management, Status Reporting
Leave a comment

Post Executive Summary:
Spend a few hours creating a central project collaboration site and save many frustrating hours of information goose-chasing (and become known as the most organized PM your team has ever had)!
Read on for more…


It’s Monday (again), and your stakeholders/managers/executives have been struck by temporary short-term memory loss.

They vaguely remember that you are at some phase of your project, just not which one.

You thought you were clear in your project status from last week on next steps, and on when your next project communication would be coming out.

 

Inevitably though, you will get a stray email or two asking the seemingly innocent question,
“Hey there awesome project person! Can you remind me what your latest project status is before I go into this board meeting?”

Get a few of these in a row, and you’ll realize how not innocent these types of questions can be. Yikes.

Wanna be one step ahead? Here’s how:

1) If you don’t already have one, create a central project collaboration site within your company’s intranet where you store all your project status emails/reports, as well as meeting minutes. (SharePoint is great for this if your company has it!)

2) Post/upload project status reports and meeting minutes to your project site before emailing them to a wide audience, and avoid forgetting to do it later!

3) Include the link to your project site within your email signature.
(And if you don’t have an email signature, what are you waiting for?!? Go make one right now, and put some personality into it!)
Bonus tip: If you are working on multiple projects (hopefully NOT, but hey we all gotta do what we gotta do), list each project’s site in your email signature so you don’t have to choose which one to include every time you send an email.

4) Send the link to the relevant sub-page or file on your project site to people who ask questions that have already been addressed.

Benefits:
By having a central project site that stores all your communications, reports, and project vital signs, you can:

  • easily direct people asking generic questions to that site (within seconds!)
  • avoid spending time digging through sent emails
  • avoid rephrasing information that has already been communicated

Soon, people will automatically go to your project site first when looking for information!

Bam! Instant productivity boost.

Now go forth and create!

Share with us:
Have you had success with having a central project site? What tools or collaboration software have you used to create yours?