New Product Development  is the art and science of bringing products to market, from idea generation through to prototyping and the first production run, and can be considered from two viewpoints – Strategic and Tactical. Project Server which is built on the SharePoint Enterprise platform is an ideal choice for meeting both the Strategic and Tactical requirements of a New Product Development system

Strategic:  
The strategic viewpoint looks at the selection and approval process to ensure that products with the best potential are brought to market as efficiently as possible.

Project Server is ideally suited for the development of a Strategic New Product Development Framework offering the following features out of the box:

• A  Stage gate approval model – used to ensure that the right products are passed through for development. An example five phase workflow is provided or workflows can be configured using Visual Studio or third party products such as Nintex Project Server Workflows.
• Portfolio Analysis – Set strategic drivers and objective criteria, which assist in scoring each product proposal, and help determine a mix of new products that is most aligned with company strategy
• Create product focussed projects – assign resources (people and materials) to these projects and view resource commitments across a portfolio of projects / new products. Avoid resource bottlenecks
• Use Project Plan schedule templates to set up predefined high level plans for new products. Develop your own best practice templates through your company’s experience and create effective development pipelines
• Manage Assumptions, Risks and Issues across all product developments
• Reporting – Harness the capabilities of Project Server and SharePoint Business Intelligence with powerful tools such as
  • Reporting Services for database reports,
  • Excel Services for dynamic charts and data grids or OLAP reporting
  • Visio Services for colourful dynamic data driven diagrams
  • Performance Point Services for the creation of Scorecards and Dashboards with multi-dimensional “slice and dice” data analytics

Tactical
The Tactical viewpoint concerns the day to day practicalities of  introducing a new product to market, and includes activities such as packaging /design workflows and the set up of design workshops.

For the tactical activities, SharePoint (which is part of a Project Server installation) has many features which enable the rapid creation of a New Product Management System including:

• Create collaborative workspaces for product based teams to share and develop ideas
• Utilise the integration between SharePoint and Project Server to raise issues and risks at a local level for visibility and review by senior portfolio managers
• Create document approval workflows for key documents such as specifications
• Create record centres for key documents with features such as version and archive control
• Create wikis to capture and develop team generated ideas or use team blogs to update others on progress
• Create custom list templates and custom electronic forms either Out of the box or through enhanced toolsets such as SharePoint Designer or InfoPath and set validation rules or attach the forms data to a workflow

Back to PointBeyond website

Let’s suppose there are 2 people involved on a project, both of which are involved on the standard tasks, but 1 of which is also responsible for project management for 20% of the project lifecycle, therefore only allowing 80% of their time to be spent on other tasks.

I created 2 standard resources Bob (who will also be the project manager) and John and changed the Units of Bob to be 80%.

I then created a third resource Bob PM and changed the Units value of that resource to be 20%. My Resource Sheet now looks as follows

Back to the plan. I entered the appropriate tasks with relevant Start Dates, Predecessors, and Work values. The project lasts 2 weeks as per the below schedule

I know the project starts on Mon 3^rd and finishes on Friday 14^th so now I just need to add in the project management activity. Bob has time available to fit in 20% project management time due to the setup of the resources earlier. I add in a project management task as a ‘hammock task’ as follows to cover the project life cycle. Copy the date from the Start cell of Task A, this is the start date of the project. Highlight the Start date for the project management task and select Paste ->Paste Special -> Paste Link from the Task tab in the ribbon and click OK. Now copy the date from the Finish cell of Task F which is the end date of the project. Highlight the Finish date for the project management task and select Paste -> Paste Special -> Paste Link from the Task tab again. I then allocate this task to the Bob PM resource and now there is 16hrs of Bob’s time allocated to project management activities covering the project time period.

As mentioned earlier there are numerous ways to accomplish this and the above method is simple and may not suit you and that are many factors to consider when managing larger scale projects with shared resources etc. Other options include creating different calendars with only a 20% working week and assigning the task to a specific calendar.
Back to the PointBeyond website

PointBeyond, the SharePoint business application specialists, together with BeMo are bringing a fresh approach to hosted Microsoft Project Server solutions in the UK market by combining their cutting edge collaboration expertise and EPM technology.

“Besides our taglines, PointBeyond and BeMo have a lot in common. In fact, we are both extremely passionate about our work and are committed to delivering the best possible collaboration solutions to our customers” said BeMo co-founder and Vice President Joel Lachance. “PointBeyond will play a pivotal role in pioneering on-demand hosted Project Server solutions in the UK while continuing to expand its unique offerings and expertise in EPM and SharePoint business applications,”  commented Lachance.

“Our new partnership with BeMo is going to enable our customers to deploy Project Server 2010 faster and with higher reliability, performance, and security than is possible with typical on-premise implementations.” said Ian Woodgate, Managing Director of PointBeyond. “With their infrastructure already safely in place, our customers will be able to more rapidly take full advantage of their new EPM capabilities and quickly start realizing a return on their investment”.

“At the end of the day, it’s all about delivering projects and portfolios to increase efficiency and performance for companies of all sizes. BeMo and PointBeyond are here to bring together the best of the best in EPM, to truly unlock the full power of Microsoft Project 2010,” commented Lachance.

For further information please contact PointBeyond at +44 (0) 207 558 8340 or BeMo at +1 702 529 0820

Back to PointBeyond web site

Sign up now to explore the benefits of Microsoft EPM solutions for yourself and investigate how these solutions could work within your organisation. Follow the scripted self-guided tours that take you through common scenarios all from your web browser.

The tours cover:

• Top down planning – showing the user interface that allows you to graphically control scheduling
• Synchronising project plans with SharePoint
• Creating new proposals for projects and starting workflow approvals
• Defining a business case
• Project portfolio management – selection and prioritisation of projects to align with key business initiatives
• Web based project management – updating time, tasks, and costs, then approving them
• Creating baselines and visually allocating resources
• Reporting and tracking progress

And if the tours aren’t for you, there is the option to go ‘off road’, allowing you to explore Project Server as a project manager and try out the activities you are most interested in. The tour databases can be reset so you can experiment with scenarios or functions multiple times. Login information will be emailed to you so you can return at any time.

This is a superb opportunity for anyone considering Enterprise Project Management wanting to satisfy their curiosity as to how things actually work and to see how the latest generation of EPM solutions can benefit their organisation.

Click here to sign up for your access to our hosted Microsoft Project Server 2010 tours.

Back to PointBeyond web site

The project is already underway and analysis is getting into full swing. It’s your first large software project and you are keen to impress your VP with how capable you are. Your ultra-busy VP has told you that there is budget for this initiative and it sounds like it has been approved by your stakeholder. You don’t know – you were not there – but you trust her. So far no ongoing issues, you report on your weekly report – on track with analysis and no complaints – the analysts are working hard and future users seem cooperative in discussing requirements. And yet you have this dull, nasty, worried and annoying feeling in the pit of your stomach just thinking of your stakeholder. Why is he ignoring you? It is personal?! Does he not care all the trouble you’ve gone to to get this far? Yet since all is quiet you carry on.

This PM is right to feel concerned. What a potential disaster waiting to happen - and this PM is not really seeing it coming. No news is not good news with stakeholder engagement. The team might well be heading for a project that is stopped and all funding pulled, or they could end up deliver something no-one wants, or there could be a massive row with the sponsor about the current lack of proper engagement.

I’ve seen projects in that boat and it never ends well. Money and time gets wasted, reputations suffer, relationships between organisational units get strained. Deal with this emergency situation immediately: you’ve lost the attention of your project sponsor and it needs to be regained at all costs. Or perhaps you never had the right person; the correct senior executive must be engaged asap.

Communication and engagement are two cornerstones of a successful project. Get these right and you are well set for the rest of the process. Chances are that faulty or absent communication, as well as shoddy stakeholder analysis, are at the core of many troubled projects.

There are several things a PM must do to rescue the situation:

- Communicate: Check you used the right communication methods with your stakeholder. A phonecall is far better than an email. A face-to-face meeting is far better than a phonecall. Call your contact and schedule a meeting in his diary via his PA. You will find that a meeting might well achieve where a dozen emails failed. You should agree ground rules for working together to ensure project success.

And whilst you are at it, check that you know and use the best way to communicate with all your project participants.

- Engage: Review your stakeholder engagement map. If you don’t have one already- write it up. It is essential to know your stakeholders – have you got the right people involved? What do you need from them, and what do they need from you? Are they going to assist you or block your progress? Do you need to influence them to convert your blockers to supporters? 

Map it all out and link your stakeholder mapping analysis into your communication plan.

Finally,

- Recognise potential issues: Tell your manager about this problem, don’t sit on it until it’s too late.

I am not suggesting that you escalate to get your boss to deal with the problem instead of yourself, but in some hierarchy-conscious organisations someone might be seen as too junior to deal with senior executives and gets ignored. It’s a terribly unprofessional practice, of course, but it’s something to be aware of.

Ksenia Woodgate

Back to the PointBeyond website

It’s really a combination of things: attitudes and qualities such as “close attention to detail”, “leaving no stone unturned”, and most importantly, “never making any assumptions”. This does not mean the PM has to do everything on a project and be everywhere at the same time, constantly breathing down people’s necks - that would clearly be unrealistic as well as annoying and unworkable for the team as a whole. PMs can and ought to delegate tasks. But even with delegating, a PM must invest a serious amount of effort to establish a reporting feedback loop and an accountability framework which then creates an environment of open, transparent and constant communication across the team and with the stakeholders. And when not delegating, a PM must make it their business to fully understand the subject matter or seek reliable expert help to ensure success. It’s common sense to all good PMs.

Project management is as much as art as it is a process. Much has been written about the process aspect of project management, and there are excellent tools available for PMs. However a part of the art of successful project management is to have this gut feel, this instinct for  sensing potential future trouble when there exists at least the tiniest lack of clarity about something the team is engaged in. And a healthily paranoid project manager should realise that if there is a little bit of scope for something going wrong as soon an a little gap in communication opens up, things will indeed go wrong given half a chance. Any unchecked assumption can blow up in your face.

So working with this instinct, a project manager should be continuously checking and validating in detail any assumptions they might have made, confirming everyone’s understanding of tasks and deadlines,  ensure sensible and pragratic process is followed, bringing people together to collaborate better, and thus work on ensuring total clarity throughout the project lifecycle.

The other day, a client with whom we’ve been working for some time asked us to proceed on a piece of work by sending me a quick note saying “please commence the work”. Some specification documents have been written, and a summary of estimated costs has of course also been presented in the past. But the client has not signed off on these in an explicit way (we are not using a document approval system with them at this present moment).

To a project manager, this lack of an explicit approval should be a concern – and my paranoia, my gut instinct tells me that this needs to be sorted out. Even though documents have been swapped at the same time as the informal approval, such a situation can be misconstrued in future and perhaps someone could claim that sign off has never been given. We would not want to risk such a situation developing, so – call me paranoid – I am seeking to have a more formal written acknowledgement of my documents.

And maybe this is a bit formalistic – and perhaps even a bit annoying to our customer whom we know well and for whom we’ve successfully delivered projects in the past. But as long as everyone is clear on the implications of this situation and the risks that both parties expose themselves to, then better and clearer communication will follow and I think we will get the project kicked off properfly in the very nearest future.

You can call it the art of project management; or you can call it common sense.

Ksenia Woodgate

Back to the PointBeyond website

As a project manager reasonably new to “Agile with Scrum” – we are keep to use it at PointBeyond and we tried that in my previous jobs, occasionally with somewhat mixed results – I wanted to share my own thoughts on the suitability of Agile to organisations’ project management processes.

It seems a good idea to carefully evaluate whether or not to adopt Agile, and to what degree to adopt it, on a case by case basis. There are places where a traditional Waterfall approach could still work. In others, Agile can be of huge benefit. It depends.

From my own experience, I can see two areas where Agile and Scrum might not work all that well. Both cases relate to organisations with cultures that are more regimented, and where trust can be an issue.

The first case is where a customer needs to fully understand the end deliverable before signing off on the dotted line to commence the project. So we are talking about a customer who is fairly inflexible in their approach. To receive a go-ahead to actually start building software, one would then need to put in place a comprehensive functional specification – which will be arrived at after a full-on analysis and design phase.

Of course, going Agile does not mean that the functional specification is necessarily dead – only that it might be short, focus on key architectural decisions which are the cornerstone of a deliverable, and focus on the critical success factors of a piece of functionality. But not all customers will grant such a degree of artistic license to the project team. And hence it can also be a question of trust in one’s professional ability, judgement and skill – is there enough of it between the customer and the vendor? Can the customer “let go” and empower the project team to work out the smaller details using a suitable Agile methodology as the project carries on, or will every question need answering in advance?

The second case is where an organisation’s senior management interferes with the Scrum process, perhaps wanting teams to achieve unrealistic targets and add to its list over and above what teams say they can do – or maybe insists on changes of priorities at short notice and still expect excellent results.

Such an approach can be destructive for any team trying to implement Scrum, as it will cancel the efforts made by the participants to work out their own capacity and commit to work on their own initiative and own understanding of their skillset. Senior management must fully buy into the Agile process and remain strictly at arm’s length. If it does not, the process will not work efficiently and result in lesser motivation and decreased productivity.

The Scrum process allows for priority calls to be made – but only at the start of each Sprint. If, half-way through a Sprint, serious external circumstances cause a massive shift in priorities rendering the current Sprint a total waste of time, the Sprint can be stopped – and this is the only time this is allowed. However if an organisation tries to change priorities half-way through a Sprint by introducing new key items into a committed iteration, whilst Scrum masters allow this to happen under pressure from management, the process can break down. Needless to say, this causes stress to all participants and often does not get the item done on time anyway.

Yet again, we are talking about trust. This time – in implementing Agile – it is between senior management of an organisation and its Product owner, the Project team, and the team’s Scrum Master. When an organisation fully empowers its employees to deliver (whichever change management method is preferred) and gives them all suitable tools to do so, it will have the greatest chance of success. And trust in it’s teams is a huge step towards such empowerment.

Ksenia Woodgate

Back to the PointBeyond website