Work by Remote

Global Knowledge recently released a whitepaper that discusses what the formal project management is and who needs it.

For the purpose of this discussion, I will to refer to PM activities in the absence of operating guidelines as “informal” project management. By contrast, project management that takes place within the restrictions of an imposed set of operating guidelines will be referred to as “formal” project management.

Continue reading…

If formal project management means setting standards to do the PM work well, then I totally support this.

Most IT projects involve geeks. I guess 99 percent of the team is geek.  All I can say is that geeks are just like you and me, only smarter, more skillful, and more serious with their craft. In other words, they’re a joy to work with.

About a couple of years ago, Chief Happiness Officer, Alexander Kjerulf, wrote an article titled how NOT to lead geeks. If you were to make each one positive, here’s how to handle your geek team.The inputs are mine based on my experience in working with them.

1. Give them the right training, and on a regular basis. Training in general is empowering. But for geeks, honing their skills is important to them. And they have the passion to learn new things or be updated on what’s the latest on their chosen field.
2. Give them recognition. Like any other worker, geeks too love to be given a pat on the back for a job well done. If you don’t know how or understand their work very well, Kjerulf suggests that you work with them so that you would know.
3. Give them reasonable work schedule. Geeks are humans, too, and although they can be workaholics, they can still be stressed out. What good is a geek if he’s overworked?
4. Talk to them in plain simple English minus management jargon. As Kjerulf said, geeks hate management-speak.
5. Do not try to outsmart or act smart with them. Admit it, if you’re not a geek or do not understand the stuff geeks do. It gets more work done and faster that way.
6. Be consistent. Probably because in IT, structure and consistency is critical, geeks also want consistent and clear directions, and policies. They hate it when they smell uncertainty and indecisiveness.
7. Connect with them. Often, because managers are not geek themselves, they tend to stay away from their geek team, and just concern themselves with the output or in the user interface, for example, of a website project. Talk to them and discuss with them tasks that are doable and not.
8. Involve them in decision making, especially when it comes to your project. For an IT project, who else understands it better than the geek team. Thus, get their ideas and suggestions and how to go about the project. There should be a collaborative effort.
9. Give them the right tools or equipment to do their tasks well. What can be most frustrating for a geek team are slow computers and lack of software. These may cost you a bit more, but just look at it as in investment where you can generate income too.
10. Recognize the creative side of geeks. Kjerulf puts it aptly, “Programming is a creative process, not an industrial one. Geeks must constantly come up with solutions to new problems and rarely ever solve the same problem twice. Therefore they need leeway and flexibility.”

[Source]

What saddens me as a project manager is to see good people go.

This may be a form of review on your project deployment. But it’s a good guide for those who are about to start a new project, too.

In every project, it’s really good to start and end with the same people or team. That way, all of you understands the project, what it entails, what the role of each member is.

You would want for example to have each team member participate in the following:

1. Initiation - Introduce the team to the project, its scope, roles and responsibilities, and deliverables.
2. Planning - Develop plans for creating the final deliverables.
3. Execution - Properly plan the work.
4. Control -Ensure that the project is progressing as planned, to account for any changes, and to make midcourse corrections that are needed to keep the project on schedule and within budget.
5. Closeout - deliverable is accepted by the customer of the project, and the project team documents what it learned that could be of value on the next project.

I got the tips above from an article on Baseline Mag. Read the rest of the article and find out how project managers can transform your business by building a process, tracking performance and helping you build best practices that work for your company.

In the vernacular, there’s a saying that goes, maraming namatay sa akala. It means that it’s not always wise to assume that a person has understood what you mean, or has gotten your message.

This did in me today.

Early on, I emailed my one team about interlinking. By this I meant that we link other pages of the site or other relevant information in the site to every relevant entry. I even included in that email, examples of interlinking, and some how to’s.

At first, I didn’t even think the samples and how to’s were necessary, thinking that I was dealing with a team who knew about this stuff already.

As I would check their reports, I found out that many of them got it. So I assumed that everyone understood it, too.

I was dead wrong!

All the while I thought this team member got what I meant by interlinking. Then just by a hunch, I checked on the links in her entries, and there I found out that she was not interlinking at all!

I panicked and so checked the outputs of other team members. Good thing, they were doing it correctly. Only one was doing it incorrectly. I called her attention to it, and my fears were confirmed. So now, she would be editing her entries, and we’d be wasting precious time doing rework.

Lessons learned:

• do not assume anything especially when you’re communicating with your team through emails and chat
• make a follow through when communication is virtual in nature
• monitor constantly, not regularly, of how your team is making progress
• I also notice that when you slacken your monitoring, they also slacken their focus

I got these from PC World:

Mistake No. 1: Projects Lack the Right Resources with the Right Skills.
Mistake No. 2: Projects Lack Experienced Project Managers.
Mistake No. 3: IT Doesn’t Follow a Standard, Repeatable Project Management Process.
Mistake No. 4: IT Gets Hamstrung by Too Much Process.
Mistake No. 5: They Don’t Track Changes to the Scope of the Project.
Mistake No. 6: They Lack Up-to-Date Data About the Status of Projects.
Mistake No. 7: They Ignore Problems.
Mistake No. 8: They Don’t Take the Time to Define the Scope of a Project.
Mistake No. 9: They Fail to See the Dependencies Between Projects.
Mistake No. 10: They Don’t Consider Murphy’s Law.
Mistake No. 11: They Give Short Shrift to Change Management.
Mistake No. 12: Project Schedules Are Incomplete.
Mistake No. 13: IT Doesn’t Push Back on Unreasonable Deadlines.
Mistake No. 14: They Don’t Communicate Well with Project Sponsors and Stakeholders.

Click here to read about each mistake’s impact.

I am most guilty of Mistake No. 10. If I were to paraphrase Mistake No. 13, I don’t push for reasonable quotas and deadlines. I can be lenient at times. I can also tweak Mistake No. 4 by saying that I get hamstrung by too much attention to details and processes. Bad, I know, and I vow to improve on this in the coming days.