Understanding the Frustration of a Project Manager

Oops

So there he was. Charlie had been assigned as lead BA on a project with an external client. “Cool” he thought, but still felt a bit nervous. There were others in his department that had been in the game longer, and he was still reeling from having the proverbial  “slap in the face” in an earlier project that had turned slightly pear-shaped..

As such, Charlie decided to ask some of his colleagues for help. They were most forthcoming, and decided to hook in other expertise. “All fine” he thought, “the more experience available in this, the better.” 

Continue reading

Related Post

Virtually working – managing virtual teams

Continue reading

Related Post

Running a perfect Enterprise Search project

How should a perfect Enterprise Search project be run?

In this post, based on a LinkedIn discussion, I describe a meeting of some of the key players in Search who get into a great discussion about how running an Enterprise Search project…


Starring

  • Charlie Hull
  • Martin White
    (Author of Enterprise Search: Enhancing Business Performance)
  • Ken Stolz
  • Otis Gospodnetić
  • Jan Høydahl
  • Stephanus van Schalkwyk
  • Helge Legernes
  • Gaston Gonzalez
  • Mike Green

 


A conversation about Running a perfect Enterprise Search project

It was Friday evening, and Charlie was meeting his friends for a drink. They all worked in IT and had, between them, years of experience, especially in enterprises and enterprise search, and liked to get together to catch up with what each was doing.

After a few pints and small talk, Charlie said “Guys, what do you all reckon would be the best way to build a large-scale enterprise search project?”

Martin, who had a lot of experience in this area, looked up and said, “The main thing is that you should never underestimate what is required to get the best from a search investment.”

Charlie nodded in agreement. “But how can we help the client understand what sort of a commitment is needed?”

Ken suggested using an Agile/Scrum approach for the analysis of what the client needed as well as the development of the search UI.

“Hear hear” called out the others. Otis took the chance to follow that up with “you need someone who really understands what search is all about”. Martin glanced at him and nodded. Otis carried on. “Someone who cares about search metrics, and knows what changes need to be made to improve them.”

Jan chimed in “I agree with you on some points. You‘ve got to make sure that you include all the stakeholders, and also, educate the customer. Get everyone in the same room, and start with a big picture, narrowing it down to what is actually required. And, yes, create demo’s of the search system using “real data”. It helps the customer understand the solution better.” “However,” he continued. “I’m still careful about forcing a Scrum approach on a customer that might be unfamiliar with it.”

Stephanus put down his glass. “I’ve just finished a Phase I implementation at a client. The critical thing is to make sure you is that you set the client’s expectations and get buy-in from their technical people. Especially in security and surfacing. And I agree with Jan. There are still a lot of companies that don’t use Agile, or Scrum, at the moment.”

Sitting next to Stephanus was Helge. He began to speak. “There are a few important things. Make sure you’ve got Ambassadors – people who really care and promote the project. And ask the important question – ‘How can the search solution support the business so that they can become more competitive?’ It might be necessary to tackle this department by department. Get the business users and content owners together, but as Stephanus just said, don’t forget IT. And make sure that the governance of the system is considered.

Stephanus smiled. “Yes – the workshop idea is a definite must.”

Gaston, who was sitting next to Charlie, said “An Agile approach has worked for me in the past. Creating prototypes is important. Most clients don’t know what they want until they see something tangible.” “Ok,” said Charlie, “how has that worked?”

Gaston continued “Build a small team consisting of  a UI designer, a developer, a search engineer, someone from the IA team, and no more than two of the business users. Having someone there from QA is also handy. Start with a couple of day-long workshops to go over project objectives, scoping and requirements gathering. Use one-week sprints, and then aim to produce workable prototypes. At the end of the week, schedule a time where the prototype can be demoed. The point is to get feedback about what is working, and what the goal for the next sprint should be.

Mike, the last one in the group, looked around at everyone, and then back at Charlie, and said. “Charlie – there’s a lot of great advice here. One important thing to remember is that you have to work with the client to ensure that the search solution is part of the strategy. As the others have already mentioned, work with the client and educate them. Getting all the stakeholders together for some common education, collaboration and planning can really go a long way towards getting the necessary buy-in and commitment needed for a successful project. It also is great for setting expectations and making sure everyone is on the same page.”

Charlie was impressed. He had some pretty smart friends. “Thank’s guys. You’ve all had some excellent points. Let me buy you all another round”.

 


 Key Takeaways – Running an Enterprise Search project

  • Don’t underestimate what is required to get the best from a search investment.
  • Lead the users through the process gently. Use demonstrations and an Agile approach when trying to understand what their real user requirements are. Do the same for the development of the search UI.
  • Have at least one person who really understands search, and search metrics.
  • Ensure that you have buy-in from the departments involved, and especially IT.
  • Produce workable prototypes – these help the users understand what they are getting.
  • Ensure that everyone involved is on the same journey – include educating the users.

 


Martin White’s book

Martin White (who was involved in this discussion) has written a book – Enterprise Search: Enhancing Business Performance. You can check it out on Amazon here.

 

Interesting Resources

  • Why All Search Projects Fail by Martin White (CMS Wire)
  • Designing the Search Experience: The Information Architecture of Discovery by Tony Russell-Rose
  • How to Evaluate Enterprise Search Options by James A Martin (CIO.com)
  • Developing an enterprise search strategy by Martin White (Intranet Focus)

 


Want to learn more?
(Important Disclosure)

Related Post

Working with Global Teams: Not all in the same room

This is part of the Working with Global Teams series

Previous Post: Working with Global Teams: Pesky Time Zones Revisited

———————————————

A friend of mine,Shoaib Ahmed, has an excellent blog on Agile, and Project Management. 

He’s based in New Zealand, and as New Zealand is literally so far away from “the rest of the world” (said with a cheeky wink), he has a pretty good idea of some of the challenges that are met when working in a globally dispersed group.

Shoaib’s latest post goes into this in more detail. He mentions things such as time difference, culture, and reporting lines. Click here to read what he says.

Related posts:

 

  • 8 Tips for Teaming Across Time Zones (openforum.com)

Related Post

Different Systems and Different Silos – A Real-life Disaster

What follows is a post that was recently published on AIIM’s site as an “Expert Blogger”. (The original can be read here)

———————————————————————–

Different Systems and Different Silos – A Real-life Disaster

Discussions had been going on for months. Plans had been drawn up. Even though the main tasks had been itemized, there was agreement that these would still have to be refined further into the project.

Nothing had been done to assign owners to the tasks, but there was a mutual agreement that whoever could, would work on each task as they saw appropriate.

In any case, the goal, and the timeline, was clear. There was no disagreement there.

Over the weeks, considerable time and resources were committed to working through the various items that made up the project task list, and the necessary information was diligently recorded, and documented.

Progress was regularly reported to the various parties involved. This was done verbally. It involved the person who took ownership of the task describing what had been done, along with what else had to be done, and any impediments that they had encountered. If they felt it was necessary the task “owner” could describe a plan of action to overcome the impediment. The other parties involved could ask for more information, or give suggestions.

Communication was informal, but each party were confident that they were apprised of task activities, and that they knew the status of the project.

Then, one day, everyone involved, got together to “walk through” the progress of the project. This involved visiting the various locations where the tasks were done. It was, essentially, an internal, informal “audit”, and a complete day was scheduled. As is necessary for such an event, all “distractions” were removed. Everyone was asked to turn off their mobile phones, Blackberries, or similar handheld devices. An extended dinner was planned. Everyone had been working hard, and this would allow them to relax, and discuss the results of the audit, as well as talk about whether the project goal was still valid, or whether it needed to be modified.

The walk through of the first task went well. The recorded information was double-checked (obviously by someone other than the task “owner”). Everything looked good. Everyone was happy. The walk-through of the second task (identifying potential candidates for future sub-tasks) also went well.

But then, major issues were starting to appear. And these were not to do with the actual data, or even with the tasks themselves.

It turned out that each party had used their own system for recording information. This meant that the data, although present, was stored in two different systems. And in each case, the data had been recorded in a way that “suited” the person entering it. This meant that there was no “common” structure, and different metadata. And there was no way to simply “merge”, or import, the data from one to the other.

Further to this, because there was no real management of the tasks (as mentioned, it was a very informal process), it turned out that there was a duplication of activities. It appeared that some of the “unassigned” tasks, had been worked on by one party without knowing that others were also working on them. Result – a duplication of data. And, with the data recorded in two disparate systems.

To fix the “problem” would involve deciding which system would be the “master” system, and then manually entering all the data, from the unwanted system, into it. It was going to be a big job, and there was a lot of tension. The elaborate dinner that was planned was called off.

At this point, I turned to my wife, and suggested that the next time we were going to move house we need to make sure that we write everything down on the same notepad, instead of each of us having our own…

Based on true-life events.


Related Post

Scrum- are there actually any rugby balls to be seen?

In an earlier post, titled “The Fast and the Furious – SCRUM“,  I talked about how I had discovered that there is another way of doing a project than following a waterfall approach. And this new way was called SCRUM.

Yeah – I thought a scrum was something that a bunch of large men did while disputing ownership over a small oval ball. Well, turns out that, actually, there is actually a  connection.

In 1986, two Japanese business experts (Hirotaka Takeuchi and Ikujiro Nonaka) published a paper in which they describe the (then) current product development process to be similar to a relay race with one group of functional specialists passing the baton to the next group.

What Takeuchi and Nonaka proposed was a different method where “a team tries to go the distance as a a unit – passing the ball back and forth”.

And this was the basis of what we know call the SCRUM methodology og project management.

You can read their paper here.

Other Great Links

  • The New New Product Development Game
  • Conversation with Ikujiro Nonaka
  • An Introduction to SCRUM
  • The SCRUM papers
  • Scrum and Kanban
  • Agile software development methodologies and how to apply them.
  • Scrum
  • A father of Scrum meets a grandfather of Scrum in Japan
  • Using Scrum in real-world game production
  • Rugby and the origins of agile (lunatractor.com)
  • Goodbye Prince II? – Raise a DP4 for the last time (chrisdixon.net)

Related Post

Agile & Prince2 – do they work together in a crisis?

Shoaib Ahmed has just written a post about Prince2 and Agile.

In it he describes how he uses Prince2 as the project management methodology with Agile practices to deliver each part of the project.

Shoaib lives in New Zealand, and is working with the Canterbury Earthquake Recovery Authority (the agency established to coordinate the recovery effort following the earthquakes of September 2010 and February 2011).

Can the two (Prince2 and Agile) be used to deliver a project in a time of crisis?

Read his post here.

 

 

Related Post

Scrum vs PRINCE2 – my thoughts

Scrum vs PRINCE2 – My thoughts

One thing I used to hate was working on Projects that had no “definition”.

They were usually just a case of stumbling along, hoping that everything was going according to plan (not that there ever was a “plan”). And then working madly at the end to get something that was close to what a sales person had promised a client.

Then I learnt about a more methodical way of carrying out a project. A way that ensured that the project was:

  • well defined,
  • had suitable requirements,
  • and had appropriate milestones against which the progress of the project could be measured.

This methodical way ensured that the correct documentation was created at the correct time, and followed a suitable life-cycle. Very much based on the PRINCE2 methodology.

And I liked this way of doing a project. It had structure. And is still very relevant and appropriate to many situations.

 


Meeting Scrum

Recently I have become more aware of the SCRUM method.

Originally I thought it was to do with the sport Rugby, and since I was brought up to worship the All Blacks (part and parcel of the culture I grew up in) I was surprised that SCRUM, in this case, had nothing to do with men in rugby jerseys fighting over possession of an oval ball.

No – SCRUM, it seems, is a “different” way of doing a project. The more I read about it, the more I thought “hey – this makes sense!”

 


Similar Roles – Different Approach

Like PRINCE2, Scrum also has a set of practices and a set of predefined roles.

PRINCE2 has it’s Executive, Key Customer and Key IT board members.

SCRUM has its SCRUMMaster, Product Owner and Team.

Further to that, while PRINCE2 is a process-driven project management method,
SCRUM is reactive/adaptive method.

This is highlighted by the fact that the SCRUM methodology involves several sprints – periods of two to four weeks – where the team work on  creating a potentially shippable product based on high-level requirements.

 


Not for everyone

This way of working is not suitable for everything.

Just imagine a company building a motorway, or a high-rise building, where every four weeks that make changes based on “high-level” requirements. In those situations, you do want your processes.

However for smaller projects, such as developing a corporate portal, or similar, the SCRUM methodology seems to really make sense. Especially when you are relying on requirements from users who don’t really understand, or know, what they want. In this case, the build it, and then “rebuild/modify” based on feedback is a faster way of working.

 


Recommended reading
(Important Disclosure)

Related Post