Friday, November 09, 2007
Brand You World -2007 Teleseminars
For career professionals they provided advise on how to apply personal branding strategies to support their career success. For HR professionals and business leaders they talked about how to discover, attract, develop and retain talent. For the business owners and solopreneurs they provided tips on how to apply personal branding strategies to grow their business.
Jason Alba, founder of Jibber Jobber talked about using personal branding to improve your job search. His advice about blogging frequently, connecting with other bloggers around your areas of interest, and using your blog to prove information to back up your claims is valuable for everyone. I also found the talk by Phil Gerbyshak, The Relationship Geek on creating a personal branding strategy both entertaining and informative.
With two phone lines over the 12 hours, they provided twenty four different talks. They plan to have links to podcast versions of the talks. I am looking forward to using the information and going back to catch some of the calls I missed.
Technorati tags: management; branding;
Monday, October 29, 2007
Choosing Empowerment Instead of Control
The focus of the book is for us to move away from bureaucratic organizations that value control, dependency and use fear. We need to value autonomy, service and contribution to our customers and the company, and create energized employees. This movement is actually easier for Project Mangers than for some functional mangers.
Most Project Managers work in a matrix organization where they do not have the control and ability to create fear in the people on the project. By the nature of the job, ownership of tasks, responsibility for the work, and accomplishing the goals reside with each of the team members. Energizing the people on the team to step up and accept this is critical for success.
To do this, we have to communicate our expectations. As Stewart Levine advises in his book, “Getting to Resolution”, both sides need to document and discuss these expectations. For the Project Manager, this means working with all the key stakeholders, including people on the team, to make sure all of the expectations are explicit instead of hidden.
As a Project Management consultant, this is critical. Both you and the hiring manager need to document and agree on the deliverables. Overtime you update the agreement as things change. This is a simple word document and not a heavy legal contract. Pulling this out periodically helps to keep both of you coordinated and ensures that the goals stay aligned.
As I rediscovered, it is also a very critical first step when you are a direct employee. This becomes even more critical when your boss is thousands of miles and several time zones away. As a Project Manager that has lead several teams with globally disbursed members, I know the value of communication. Being on the other end of the relationship, I discovered that I was not able to drive, influence, or create a communications path. As the saying goes, the tail cannot wag the dog.
Technorati tags: project management; program management; management;
Wednesday, September 12, 2007
Remember, Quality is the Hidden Fourth Constraint
It is vital that the project manager work with the customer to get this definition stated in a clear and measurable way. That definition will impact the other three metric. The project manager and customer have to reach an agreement and an understanding on how this measurement relates to the other three. With this in hand, the project manager can make intelligent trade-offs and provide status reporting to the customer.
Everyone on the team also needs to understand the minimum level of quality and how that impacts their actions and deliverables. Any time that this is threaten, begins to impact the other three, or is impacted by the other three, this needs to be made visible to everyone. We are use to asking how each decision impacts time, costs, and resources. Everyone needs to also ask how the decision impacts quality.
Too many times the drivers on the project are to do it fast and cheap. That has resulted in large numbers of projects that fail or fail to satisfy the user. Budgets escalate and delivery dates stretch out as we get caught in the cycle of test, reject, and rework. The unfortunate fact for the project manager is that the same people that forced them down the road of fast and cheap will be the first to throw stones at them for missing deadlines, overrunning the budget and delivering something that is unusable.
Technorati tags: project management; program management;quality;
Friday, May 18, 2007
All Project Managers should be part of the Department Of Doing
Many times people only define the Project Manager role around budgets, schedules and resources. While they are important, it is more important that the project deliver a usable solution aligned with the business need. When a project tends to stray from one of these measurements (admit it, they all will), instead of blindly stuffing it back onto the track, we need to use that as an opportunity to step back and take another look. This is the chance to pull the two hidden components, quality and usability, out into the light. Instead of blindly pushing to get back on schedule, on budget, or get more resources, let us ask if we are still on track to deliver a usable solution at the right level of quality.
In Jeff Pfeffer and Robert Sutton’s 1998 book, The Knowing-Doing Gap: How Smart Companies Turn Knowledge Into Action, they pointed out that organizations and people can know the right thing to do but do not take the right actions to make it happen. Too many times talking about the problem or solutions are a substitute for taking right action. As a Project Manager, we see these at Lesson Learned meeting, status meetings, and project reviews.
As the Project Manager, everyone looks to us to “get it done”. Leading cross functional teams in a matrix environment, we must be vigilant. We need to make sure we are translating the ideas into a usable solution at the right level of quality. We must weed out and eradicate the tendency to substitute talk for action. At the end of the day, being able to say you were on time, within budget and did not need more resources does not win points if the deliverables do not match a strategic business need and are not usable.
Technorati tags: project management; program management;
Friday, January 12, 2007
Aligning Strategic Business Goals with Project Goals
The tool allows you to easily create and modify the form, apply rules to the fields, and control access. We have the ability to store things on the Intuit server or to link to documents in our SharePoint within the firewall. I also set it up to limit edit permission for some fields based on the person's role. Over the five months that we have been using it, it has proven flexible enough to allow changing the entire form layout, adding the off shore development team and their managers, and shifting the information as we change the process flow.
There were a number of things driving the company to set this up and use it. The major reason was the failure to get projects done on time. As is the case in most growing companies, resource assignment and usage was not visible to management. With a number of business development people getting new customers the delivery dates overlapped and created too many urgent projects. These were starting to displace the important projects, and the negative impacts on the Engineering resources were not visible.
Creating the structure and process flow was the easy part. Changing behavior so that the tool is used, people enter the right information in a timely manner, and management shifts from wanting to do everything to limiting the work to what can get done at the right level of quality is the current challenge. Currently we are working through the issues around ranking and comparing marketing (Return on Investment (ROI) focused) projects, with Engineering (process improvement and quality focused) projects, and maintenance (adding and improving data, and implementing fixes focused) projects. All of these are important. The key is balancing all of these as we move forward.
Technorati tags: project management; program management; Intuit Quickbase;
Saturday, June 24, 2006
Processes, Projects, and Programs - OH My!
Handling multiple projects can lead to the work creeping upward into the area of Program Management. This is where the view shifts from getting the work on a project done to looking at the business strategy and how all the projects fit. The focus shifts into prioritization between projects, resource allocation on a larger scale, risk management that focuses on the impacts to the business, and the processes around starting, tracking, reporting, killing, and completing projects.
An operational process is an on-going set of tasks and most are focused on the day to day work supporting the organization. Work targeted at improving these fall into the continuous process improvement area. Because a project can be used to implement a significant change to one of these processes, there can be confusion. Some of that confusion contributes to the resistance to killing a project. It also is a factor in the reluctance to declare a project finished. This desire to call everything a project is especially strong if the business groups know that a process is not working well but do not know how to fix it. A transition from a project that is going well into a poorly run process is another reason that the business would want the project to continue.
The skill sets and expertise that makes you good at each of these is a little different. It is not difficult for the same person to be good at all three. The critical thing is to know when the work has shifted from one to another. On a recent consulting assignment, I set up the Program Management structure, creating forms, processes, and presentation formats. This provided a standardized method to request to start a project, track and report on-going projects, and prioritize the projects. On some of the projects, I was also the Project Manager, working to collect requirements, define and assign tasks, determine deliverables, etc.
I had set up and improved operational processes before, so I knew I had the expertise. But I was brought in as the Project Manager. I resisted attempts to get me to take over someone else’s area and fix the operational processes, too. I had continuous discussions explaining how a project and process are different. There were some attempts to disguise a broken process as a project. After some work and digging, I would unmask these impostors.
Setting up the program and project parts are important and a significant amount of work. The reality is that most, if not all, projects end up sitting on top of operational processes. The project initiation form collected the assumptions, constraints, and the fact that changing the processes were out of scope. The risk management documented these processes as risks items. None of that saved us. Projects became derailed, delayed, and negatively impacted because they were sitting on top of a bad process.
Next time, I will get into the mud and help shore up the process foundation. This will not be glamorous. It will also require skillfully navigating between two sharp and jagged rocks. One side is educating management that processes need repair. The other is avoiding having the people working on those processes see my work as a threat.
Technorati tags: project management; software;program management;
Friday, March 24, 2006
Bamboo and Project Management
Ok, it is a great metaphor, but how do we turn that into action? The obvious but often overlooked starting point is to keep it simple. People, especially senior mangers, need to see the message with minimal explanation. While a number have are familiar with Gantt charts and other views from project software, it is not the right answer for everyone. So, I start with a pretty picture on a MS PowerPoint slide. The picture should show everyone, at-a-glance, what projects are underway, top level time based depiction of each phase in each project, and a simple stoplight color scheme to illustrate the project status. Based on that one slide, we have a great deal of information to talk about resources, risks, project portfolio management, and candidates for extra resources or termination.
Of course, a large amount of detail and data needs to be collected and analyzed to create that simple picture. I do not think that this task should mandate using any specific tool. Instead, you should be free to use or not to use any tool or software that makes collecting and updating the information easy. I have worked at places where they had a full time person whose job was to update a MS Project schedule each day. Projects that have short durations or are in a high state of change need a more light weight and flexible approach.
I found that giving the tasks owners a simple template in MS Word or MS Excel provides enough structure and easily gets me the information I need. But there is one hole in this system that still needs to be plugged, tracking resources for each task. If you are careful, you can use MS Project to map it out. And this can serve as the building block when you need to show an “official” project Gantt chart.
Keeping the Project Management structure flexible and light weight, like bamboo, provides the tools to support the work without diverting a large amount of work into changing the scaffolding when the project changes. This approach is even more useful when you are introducing Project Management into an organization.
Technorati tags: project management; software;
Tuesday, January 31, 2006
Software Project Management – shifting from a directed to a collaborative model
Dr. Barry Boehm published a new approach, the Spiral Software Development model, in 1988. This was a way to address the IKIWISI syndrome ("I can't tell you, but I'll know it when I see it”). In recent years, a number of new techniques have been created to address the problem of the customer not being able to give you all the requirements since they do not know all the requirements at the start of the project. Most of the techniques try to address this problem by developing what you know as fast as you can, so that you can present it to the customer. As the customer sees more of the software “functioning”, they can do a better job of clarifying the requirements. This happened in the earlier methods but was seen as “scope creep”. Due to this new information and requirements appearing late in the development, it was very costly to add the changes. That created an elaborate change management system which tried to reduce the number of changes.
The biggest change that has occurred from using the new methods is that the relationship between the project team and the customer has shifted. Instead of the project team being directed by the customer, we have shifted to a collaboration model where the project team and the customer work together. This is an important and critical change if we want to develop complex software projects that will be usable and support the business goals. The software project manager’s work shifted from coloring in triangles on a chart and driving work to fit to the plan, to that of a navigator.
As the project navigator, the job is to scan the horizon for changes, work with the customer to determine if the change impacts their goals, and then using that information to keep the project team on course. Continuous collaboration is now the key skill of the software project manager. The shift in the role of the customer means that they need to be more involved and need to work with the development team to surface decision points, eliminate undocumented programmer assumptions, and understand the trade-offs.
The current methodologies and techniques all work well in specific situations. Selecting the one best one will depend on the business culture and processes, the training and flexibility of the team members, and whether the requirements will change over the course of development. No matter which one you use, the software project manager has to keep the customer engaged and involved.
Technorati tags: project management; software;
Tuesday, December 13, 2005
Poor designers choose to user the Mailto function
Technorati tags: Web Design; security; internet
Tuesday, December 06, 2005
“Email a Friend” especially a Spammer
After reputable companies became concerned about privacy, they started to add a privacy policy to their websites and to switch to an “opt in” process for marketing email. That meant that the marketing folks could only send you an email if you gave them permission. Some clever marketing folks developed the “Email a Friend” function to get around this annoyance.
The function has several names but they all work in a similar manner. Selecting this feature, you are presented with three input boxes. You are asked to put your email address, the email address of your friend and some clever words to send to the friend. The function creates an email from you to your friend, adds some marketing message about how great the product/site/service/etc is on this page, and adds your comment. Since the email appears to be from you, then the marketing folks can weasel around the privacy issue.
Of course this is ripe for abuse and with a few lines of code can be turned into a great non-traceable spambot or even used to flood an email and perhaps create a denial of service. If the clever spammer puts an email address from an employee of the company, it adds even more fun. Since the company email server sent it out, it becomes hard to claim that someone else sent it. In addition to flooding an email box, a truly angry spammer can also add some very abusive and profane comments in the little text box.
Should this little tool cause an email server to clog and possible to shut down, then the target may call in the lawyers. While you may be able to claim that the person in the “from” line did not send out the email, you are still responsible for the misuse. If you want to appear as a leading edge technology company or want to sell technology services to other companies, the bad press alone will cause a large chunk of revenue.
In a company I worked at, we had one of these popup on a website. When confronted with the potential danger, the marketing person’s response was that very few people use it and no one has abused it yet. Some how leaving a loaded gun on the street and claiming that it was Ok since no one was shot yet seemed a bit weak. After a chat with our legal folks, a quick directive landed on the desk of that marketing person’s top management ordering that it get removed immediately.
Somehow adding a function to one company website that is reckless and dangerous, has no measurable benefits, and is rarely used by the customers does not strike me as a good idea.
Technorati tags: Web Design; security; internet