Unauthorized use and/or duplication of this material without express and written permission from this blog’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to John D Carmack and Random Acts of IT Project Management with appropriate and specific direction to the original content.

Tech

Archive for April, 2009

It never ceases to amaze me just how complicated people can make things. Human beings have a remarkable capacity to overcomplicate things.

Let’s take project management. You plan it. You do it. You evaluate how you did. So, what’s the problem? Usually, the problem is that people are involved. You not only have to manage risks and issues, but you have to be aware of the human potential for creating risks and issues independently.

A co-worker manager once remarked that managing software developers is like herding cats. I cannot take offense at that, as I know I resemble that remark. Cats are independent and unpredictable. People are too. Software engineers are sometimes even more-so. In an effort to work out all contingencies and to be all things to all people, software developers will sometimes code in things that are too complex for what is needed.

A good PM needs to be mindful of these things and be able to cut through the noise. Simplify, simplify, simplify. Even doing a WBS is an exercise in breaking the complex down into simpler more manageable components.

That doesn’t mean that things don’t just plain go wrong. In fact, I’ve noticed that things go wrong every day. On a good day, perhaps only one thing will go wrong.

However, how your team reacts to these events can make things better or can make things a lot worse. This is where the PM must put on their motivational hat and get the responsible party or entire team to focus.

I had a conversation earlier this week that bowled me over. One of the people was making a big deal out of implementation. All I could think was, “Why is he making this so hard?” and “Why is he making a big deal about this?”

Things go wrong. We all know that things can and do go wrong during implementation. What causes things to go wrong at implementation? I mean big things; I mean things that go terribly wrong.

Someone wasn’t doing their job. Unfortunately, this is usually the cause. Someone overlooked something, had a hidden agenda or otherwise had a “human moment”. We’ve all done it (well, except hopefully the hidden agenda part). That “someone” may be a developer, a tester, a manager or even the customer. Yes, the customer has a job too, and it is your job as the PM to gently remind them of that if they forget, just as you would any other member of the team (including yourself!).

It just plain wasn’t meant to work right, at least the first time. It might be an act of God, nature or just plain chance.

These are both tricky. In some environments, even the latter category can be a political nightmare.

When someone fell down on the job or even if they fell asleep at the wheel entirely, it is helpful to remind yourself of all the good the person has done throughout the project. Go over this list at least 3 times before you have a chat with them. If you have difficulty thinking of anything substantial they have done right during the project, at least one of you definitely has a more severe problem.

Some things just are going to happen. Some things may be more predictable than others, and it is prudent to ask if reasonable steps were taken to mitigate such a situation. It is unlikely you can predict a lightening strike during a rollout. However, if all that occurred was that the power grid was knocked out, then a reasonable effort would have been to ensure servers are on backup power. The question remaining would be if a remote PC console would be on a UPS under reasonable circumstances.

One thing about a rollout is that it is the culmination of effort up to that point. The implementation phase is that iswhere the entire project will either be deemed a success or failure. There is very little ground in the middle. If contingencies have been planned throughout the project, it will likely be a successful implementation. Otherwise, it could be a nightmare. The implementation will be a culmination of not only the smaller successes along the way but also a culmination of the smaller failures made along the way.

When things go wrong during implementation, they are either from mistakes made much earlier in the process or they are things over which no one would have reasonably planned. Implementation issues are rarely exactly that, as even the planning for implementation needs to take place before the actual event.

I was reading a job description last week. They wanted someone who was “experienced in Web 3.0”. Say what? Must be a typo. So, imagine my surprise when I see the same ad a few days later in another place. Not sure how you can be “experienced” in something that mostly only exists on paper right now. If you thought “Web 2.0” was nebulous, try explaining “Web 3.0”!

Web 2.0 was a buzzword created by Dale Dougherty of O’Reilly Media.1 However, the father of the World Wide Web (WWW), Tim Berners-Lee disputes that the term is all hype. He maintains that it is nothing more than what the WWW was intended to do.2

Instead of “Web 3.0”, Berners-Lee sees the future as being a “Semantic Web”.

Web 3.0 and Semantic Web have a few things in common. The goal is to make the web smarter. Right now, computers can search and serve up pages, but to make them truly useful requires input from a human. So, how can computers themselves learn and serve up more meaningful information that requires less human parsing?

Software agents seem to be key. In Berners-Lee’s scenario, the web would be organized into ontologies defined by metadata. Some of the groundwork for this exists with people tagging different web pages and bits of information. Agents would then utilize the metadata to personalize the information. The question is whether or not people will expend the effort for tagging, though.

Another piece to the Web 3.0 puzzle will be a user’s profile. Again, there are some systems that can use input from a user to provide individualized content. However, these current systems are not yet nearly ready for prime time. They don’t truly “learn” yet, and there is a lot of training involved.

What about applications, though? Well, it could be done via mashup, much as some applications do now.3 The API, aggregation, application and client-side services will all need improvements and standardization.4 There have been improvements since Wainwright’s article, but it looks like things need to shake out a lot more yet.

These things do not come without certain implications, though. For example, what if the information in a user’s profile were revealed to people with harmful intent? Would it decrease privacy? Would it make it easier for identity theft? These actually may not be resolved before the technology is in place and in use.

I will keep this brief. I’m a little under the weather. You have that thing to do. In fact, there are a lot of things to do, and there isn’t enough time to do them all. Information overload. Downsizing leads to wearing yet another hat. The work still needs to be done.

As a project manager, you will be faced with time constraints. No, not just project time constraints, but you will be faced with day to day time constraints. You must be able to juggle many things. How do you get them all done?

The short answer is: You don’t!

If you haven’t learned anything from The Dip yet, you need to prioritize what is important and what is not. You need to stop or delegate what is unimportant so you have time to do your job. This is very important in an economy where your job may have previously been done by 3 people. Identify what each of those 3 people did that was important and discard or delegate the rest.

Ilya Bogorad wrote in a TechRepublic article on 17 April about “10 faulty beliefs that can doom IT leaders”. 2 of them should make an average PM think: “We are a fast-paced organization”, and “We are under-resourced”. Have you ever been anywhere in which the organization ever said “We are laid-back” or “We have too many people”?

Could the problem be that the important things are not being given the proper priority?

The term “Agile” has become such a buzzword that it has lost its meaning in the current development environment. To paraphrase an old joke, if you ask 4 IT managers what Agile is, you’ll get 5 different answers. Some will interchange the usage of “Scrum” and “Agile”, but is that the correct usage of these terms? What is the difference between “Scrum”, “XP” and “Agile”?

Yahoo! Tech news reported on 24 April that the “Conficker virus begins to attack PCs: experts”. Some considered it an April Fools joke, but soon after 1 April, the virus activated and began searching the Internet for downloads.

One of the things Conficker does is prevent you from accessing standard antivirus web sites. That is why there is a Conficker Eye Chart that helps determine if those sites are blocked or not.

What does it mean to be the best? According to Seth Godin in The Dip, it doesn’t mean being just a little bit ahead of everyone else. Many of his examples show that market leaders are often 3 times or more ahead of their competition.

Market leaders do understand what others do not about their markets, which is why they are the market leaders.

Reisinger goes on to ponder, “Where are the growing startups like Wikia or Quintura? Why haven’t Microsoft or Yahoo gained any ground on Google in the US?” While he states a few hypotheses as to why, according to Godin this is normal if a company is going to remain the market leader.

Project Management Professionals (PMPs) are credentialed because they are the best. They are required to have a mix of education and experience before they can even take the test. They are the pack leaders.

However, you cannot stop there. Once you are among the best, you must differentiate yourself as the best of the best.

There will be a webinar on Thursday, 30 April 2009 at 2:00 pm EDT on Agile Requirements (Not an Oxymoron). The speaker will be Ellen Gottesdiener of EBG Consulting. She is an internationally recognized expert on collaborative requirements development.

MS Project is undoubtedly the most widely known tool in the project management (PM) field. After it might come a myriad of clones and/or ERP solutions.

However, I would argue that MS Office actually should be inserted between those two. Did you know you can do Gantt charts in Excel? Some people actually track projects using Excel. There are even templates for doing this. That might be more at the extreme end, though. MS Word, PowerPoint and Visio, or perhaps OpenOffice equivalents, are all part of the PM toolbox.

I’ve never really understood why I need another application to do diagrams, though. Visio can be expensive on top of that. What if all you want to do is flowcharts, and only occasionally at that?

What is Squidoo? It is an online publishing tool, but it also is much more! You can create your own "lens" (Squidoo-speak for a web page), and it can contain all sorts of customizable widgets to suit your needs. If you are good at putting together web pages and attracting people to them, you can also attract people to your lens and under some circumstances earn money. You can interact wth other Squidoo users. You can setup a lens to attract people to your blogs and web sites. Basically, you can do just about anything but create spam!

Failure is instructive. Most of us have an instinctive aversion to discussing weakness, based on concerns that criticism may hurt our pride, reputation, and so on. While I deeply respect these sensitivities, fear creates an environment where repeated cycles of failure can manifest. Breaking this cycle requires understanding the source of problems followed by developing solutions to address them.

Failure causes you to learn. Hopefully, success does as well. Humans have an amazing capacity to learn, and we should do so at every opportunity. If we do not learn, we do not improve professionally or grow personally.

Teams and even companies can learn as well. That’s why Bowers’ article is so important. If teams and companies cannot face the facts and learn, then they never improve. Projects will continue to fail.

A thorough “lessons learned” or “after action” review is a must. The US Army has a tradition of sending soldiers on field exercises and then holding after action reviews afterwards to grade themselves. Self-reflection is the key to improvement.

That’s why in the long run requirements gathering just plain is not as important! Why? Because a thorough lessons learned review will uncover it as a weakness and make recommendations to fix the problem. If you do lessons learned poorly or not at all, you will never know if your requirements gathering is any good or not!

What if you had a project to create a product, it was done on time and under budget, it was delivered and the customer never complained. Was the project a success? How do you know?

There is a saying that for every customer that complains, there are 9 others who have the same problem but do not complain. It could be because they are too busy or too tired, or maybe they don’t know who to complain to. Just because no one complains does not mean the project was a success. Again, you have to gather data after the main portions of the project have been completed.

The fact that I’ve changed my mind about “requirements gathering” is proof I’m not too old to learn. 🙂